[PATCH 3 of 5] Add option to heads to show only heads for current branch
Alexis S. L. Carvalho
alexis at cecm.usp.br
Tue Jun 5 15:01:03 CDT 2007
Thus spake Eric Hopper:
> On 6/5/07, Alexis S. L. Carvalho <alexis at cecm.usp.br> wrote:
> >The heads command in 0.9.3 (which is still the most recent version)
> >still has a -b/--branches option for old-style branches...
> >This interface also requires a "hg branch foo; hg heads -b" to see the
> >heads of a non-current branch, which is not exactly optimal, and which
> >just won't work if you can't write .hg/branch.
> >Maybe "hg [-b] [branch]" (-b is still a boolean option) - if you specify
> >branch, print heads of that branch; if you specify -b, print heads of
> >the current branch; if you specify both, err...
> I thought the same thing and came against the same set of difficulties,
> whereupon I decided that just having -b was good enough. :-) If you can
> think of something better, I would love to hear it.
My wishlist would be to have fuller support for multi-headed branches:
- save all the heads of all branches in the cache
- commands with a --rev option that accepts a single revision (e.g. cat
or even diff) error out if you specify a branch with more than one
head (or maybe just use the branch tip, just like now)
- commands with a --rev option that accepts many revisions and/or
commands that accept multiple --rev options (e.g. log, pull, push,
clone) use all the heads of the branch
- hg merge without arguments tries to merge with the other head in this
branch, error out if there's more than one other head
The error message for specifying a multi-headed branch when a single
revision was expected would suggest using "hg log -r <rev>" to get the
list of revisions specified by that name.
And that "hg log -r branch" would be the way to get all heads of the
> >I'd say that using rev/parentrevs/nullrev would be a bit faster, but
> >since you're reading a good chunk of the changelog, that probably won't
> >be noticeable. The dict.fromkeys([...]) in the loop also look somewhat
> I wish there were a method to just get the non-null parents. I think there
> are several places where that would be helpful.
> >We should probably just save all the heads in the branch cache.
> And make the branch cache that much more complicated? I'm not so sure.
See comments above.
> >Extra brownie points if you make the exit code non-zero when you print
> >the warnings.
> >Maybe the warnings should be printed only with --verbose? Or maybe
> >--quiet should suppress them...
> Hmmm... not sure if that's right. I think there should be a non-zero code
> returned only for a definite error situation. All of those count as an
> unusual or surprising situation someone should know about, but not exactly
> an error.
I saw the start (or startrev?) stuff in heads/bheads and was wondering
when it would be useful. One thing that I thought of is that it'd be a
nice way to answer "is revision R included in branch B?": just use --rev
and specify the branch name. To use that in a script it'd be nice to
have a different error code.
> Having --quiet suppress warnings (which is how I think it ought to work if
> it's done) is beyond the scope of my change, and should be done on a global
> UI level anyway. :-)
I was thinking of the above script scenario - it'd be nice to just
suppress the error message, but the script could also just redirect
More information about the Mercurial-devel