Re: I just pulled and built 'next'...

["Shawn O. Pearce" <spearce@spearce.org>]

Uwe Kleine-K?nig <zeisberg@informatik.uni-freiburg.de> wrote:
> Shawn O. Pearce wrote:
> >   $ git rev-list v1.5.0-rc0..next | wc -l
> >   687
> >   $ git rev-list v1.4.4.4..next | wc -l
> >   1051
> > 
> > So what about doing Junio's suggestion of going by topology and
> > coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4
> > right now), and if more than one is found compute the number of
> > commits between each tag and the requested revision, and take the
> > tag that has a smallest number of commits?
>
> One scenario where this will fail is when a bugfix is commited on top of
> v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.

Actually it still works, and does what you want.  The scenario you
are describing is exactly the one that caused this bug to appear,
and is the one my suggestion is trying to offer a partly sane
solution to.

Try it.  Checkout v1.4.4.4, make a trivial commit, merge it to
master, then merge that to next.  You'll still come up with the fact
that master (or next) have less commits different from v1.5.0-rc0
than they have from your hypothetical v1.4.4.5.  In this case the
the v1.5.0-rc0 tag should still be taken.

Its easy to explain this difference in terms of what the user
sees via `git log` and `git rev-list`.  We're taking the tag which
has the fewest commits different.  This will hold even if `next`
suddenly gets another 800 new commits (changing the above counts
to 1847 and 1851 respectively).


Where it might fail is if v1.4.4.5 suddenly gets another 1000 commits
as part of its bug fix release and those all get merged into next.
Now v1.4.4.5 is closer than v1.5.0-rc0.  But you know what, that
does still make a lot of sense.  If you look at the git log (or
git shortlog) between v1.4.4.5 and next there's less output than
if you look at it between v1.5.0-rc0 and next.

-- 
Shawn.