Re: [StGIT RFC] Changing patch@branch syntax

["Catalin Marinas" <catalin.marinas@gmail.com>]

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.

> > 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.

> 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.

> > >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.

> 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.

> 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).

> > 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