[PATCH 3 of 5] Add option to heads to show only heads for current branch

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

This warning should be in commands.py


Thanks.  I'll look into changing the code to propagate errors back out to
commands.py which then turns them into warnings.

Some comments outlining the algorithm (or at least the basic idea) would
> be nice.


Yes, you're right.  It wasn't hard to think of, but it wasn't trivial
either.

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.

My general strategy for making optimal Python is to make sure Python spends
as much time executing C code as possible.  Hence dict.fromkeys and
dict.update rather than an in-Python set of if statements.  Though, in this
case the dict creation overhead might dwarf the speed hit of executing a
bunch of Python code.

In that vein, perhaps just stuffing the parent list into the dictionary then
removing the nullid entry would be best.

And I didn't know that revparents existed.  So maybe I will use that because
you're right, it should be faster.

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.

This warning should also go in commands.py (without the extra space
> after "No").  You probably want to test for "not heads", since
> len(heads) is probably never negative :)


Good catch.  I meant <= 0.  I always like to make sure that 'impossible'
situations result in sane behavior so I'd generally prefer to not use 'not
heads'.  I need to put things that catch this problem in the tests.  :-)

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.

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

Thanks for your comments,
-- 
Eric Hopper -- http://www.omnifarious.org/~hopper/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20070605/22cc11b8/attachment.htm