On 24/06/07, Yann Dirson <ydirson@xxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
