[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
> >heavy-handed.
> 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 mailing list