Dana How [off-list ref] writes:
It is based on "next" in order to incorporate Nicolas Pitre's work.
Heh, since last night, 'master' and 'next' points at exactly the
same tree object, although their commit ancestry are vastly
different for obvious reasons.
Which leaves 'master' right now at v1.5.2-rc1 while 'next' at
v1.5.2-rc1-687-gcb3892c; we might want to do something about
this apparent discrepancy.
Junio C Hamano [off-list ref] wrote:
Heh, since last night, 'master' and 'next' points at exactly the
same tree object, although their commit ancestry are vastly
different for obvious reasons.
Which leaves 'master' right now at v1.5.2-rc1 while 'next' at
v1.5.2-rc1-687-gcb3892c; we might want to do something about
this apparent discrepancy.
Are you considering rewinding next to master? I'm not sure how
else we could cancel out all of those merges and reverts of bad
ideas from next.
One option might be to teach git-describe to look for matching trees,
and see if git-describe could match the tree that v1.5.2-rc1 points
at with the tree that cb3892c points and, and just call the latter
the former... But that sounds a little risky to me in some projects,
I'm not convinced that is always the right way to describe a history.
--
Shawn.
On Tuesday 2007 May 01, Junio C Hamano wrote:
Which leaves 'master' right now at v1.5.2-rc1 while 'next' at
v1.5.2-rc1-687-gcb3892c; we might want to do something about
this apparent discrepancy.
It's perfect - I'd say that it's exactly right.
git-describe is for making unique - human readable names for points in
history, not for describing the tree. It makes no difference that A and B
have the same tree, they are different points.
I've always thought of git-describe as being a way of mapping a commit hash to
a nicer looking name. If A and B are different commits then they should have
different names.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com