Re: [StGIT RFC] Changing patch@branch syntax

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jun 25, 2007, 22:22 UTC
Message-ID: <b0943d9e0706251522s6baf7997r48beae7f57681d77@mail.gmail.com>
In-Reply-To: <20070624212603.GA6361@nan92-1-81-57-214-146.fbx.proxad.net>

On 24/06/07, Yann Dirson <ydirson@altern.org> wrote:

> Well, currently "stg show <stack>" will just take <stack> as a git
> ref, and will show the top commit, which may well be the base commit
> of the stack - not very exciting, I agree.

Indeed. The 'show' command was meant for patches but I added the support to fall back to git commits.

Show 8 quoted lines

> > What might be easier with a complete spec is bash completion. I find
> > this mandatory precise description similar to the Hungarian notation.
> > Since most of the time I work with push/pop commands, I don't like
> > always putting a ":" for every patch
>
> Right, push/pop should only get the local name in the current
> patchset, no ":" whatsoever in there.  It is not the same for "show",
> since we often want to look at patches in other stacks.

Yes, but most of the time I look at patches on the current branch.

Show 5 quoted lines

> I have often wondered if it would be useful to have a given
> patch@stack as a base for another stack, or maybe as one of the
> "heads" of an hydra.  Still not sure it would make any sense, however
> - especially, proper use of hydras would possibly suppress the need
> for the former.

There are situations when I want a separate branch but it relies on patches in other branches. I currently duplicate the patches and use the 'sync' command to keep them up to date (though this command would be more useful with support for git-rerere to avoid fixing the same conflict several times).

Can a patch series be part of multiple pools? This would be useful to my workflow.

Show 11 quoted lines

> > >I'd rather having a single name-resolution mechanism, instead of one
> > >for patches and one for branches.
> >
> > I don't see why we couldn't have a single name resolution but without
> > the mandatory ":". An example (but in reverse order) is internet
> > names. I only type "intranet" rather than "intranet." in a browser. To
> > fully qualify, I type "intranet.arm.com".
>
> There is a difference, in that in name resolution there is a
> well-define algorithm to resolve this, and in that "intranet" alone is
> not a valid fully-qualified name.

No, it's not fully qualified but it gets the .arm.com by default. If it fails, the browser will complain.

> In current StGIT, in cases where
> "name" matches both a local patch a git ref... well, we can still ask
> for refs/heads/name as fully-qualified name - looks like I had
> forgotten that one ;)

StGIT could default to patches and fall back to git commits if no ":" are found in the name.

Show 17 quoted lines

> Let's try to find a proper solution.
>
> We have on one hand a number of commands (in the patch/stack sets)
> that act solely within the patchset, and thus have no need for
> referencing stackables outside the current patchset:
>
>         new, push, pop, goto, float, sink, clean, uncommit, export,
>         import, mail, refresh
>
> Similar commands, but which no technical issue restrain from acting on
> stackables in other patchsets:
>
>         delete, hide, unhide, patches, series, files, log, rename, show
>
> Commands that solely refer to patchsets, not stackables:
>
>         applied, unapplied, top, branch, rebase

Those that can refer to other patchsets have the '--branch' argument, otherwise they just use the current series.

Show 13 quoted lines

> Commands that need to refer to patches in other patchsets:
>
>         pick
>
> Commands that don't care:
>
>         assimilate, commit, init, pull, fold
>
>
> I consider we have a couple of special cases:
>
>         clean currently does not care, but see task #5235
>         rebase currently only needs patchets, do we need to extend that to patches ?

'rebase' could only work on the current patchset because of the possibility of getting conflicts during push (unless you implement the branch switching as well).

>         mail currently does not accept --branch or patch@stack but probably could

Yes.

>         new creates a patch in the current stack, we may want to unify
>                 this with "branch -c" in some way (maybe "stg
>                 (patch|stack|pool) new" ?)

This might be a possibility once we refactor the command line.

>         show is special in that when its arg is not a ref to a patch,
>                 it falls back to git-show.  We may want to change
>                 that, to be an stgit-only command.

We need the commit id generation for the 'pick' command and 'show' would use the same code. I don't think we should restrict it.

>         sync uses non-standard way to refer to the other stack - do we
>                 really need to sync several patches in one command ?

I have stacks with more than 10 common patches and it is useful to update them with only one command (I do this many times only as a simple check).

>         clone is also special, in that it is currently the only one to
>                 have a use for the repo - it could surely be extended
>                 to accept a stackable (eg. "stg clone http://this/repo#pool2:stk1")

Yes, it would be nice.

> To summarize, appart from "show" which does not really need to know
> about branches, no current command would have any ambiguity.

If we don't want ambiguities in the UI, we could restrict 'show' only to the StGIT patches (though I personally don't mind the fall-back to GIT objects).

Show 5 quoted lines

> > Also, shourt stgit/git.py be aware of the repository?
>
> I'd rather think that we should have git.Repository (and further
> structurate git.py with more objects, like git.Branch), with
> stgit-specific stuff in the stgit.Repository subclass.

Sounds good.

Thanks.

-- 
Catalin