Linus Torvalds <torvalds@xxxxxxxx> writes:
> On Sat, 30 Sep 2006, Junio C Hamano wrote:
>
>> Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>>
>> > Agreed. I've been missing such a command and have wanted to add
>> > one but it wasn't important enough to me to actually code it. :)
>>
>> Everything you said in your message sounds sane and makes sense
>> to me. Now we have to find a sucker^Wvolunteer to implement it
>> ;-).
>
> Ehh. As far as I can see it's
> - a damn hard thing to do efficiently
> - essentially exactly the same problem you already solved with "git
> describe"
>
> In other words, I think you could make git describe do it, by simply
> making it parse not just all tags, but also walking the branch log.
As a user interface, I think it makes a lot of sense to have
"git describe" do it without introducing a new command.
However, I think the traditional "find the closest ancestor"
behaviour and ref-log behaviour are mutually incompatible, while
they both return information to help address similar issues to
the end user when viewed at a very high level.
Especially, "find the closest ancestor" behaviour means when you
get "tag-gXXXX" as an answer, the tag proper does _not_ contain
the given commit (e.g. commit v1.4.2-g4839bd8 is not part of
v1.4.2). To answer "when did the fix deadbeef go into master
branch", reporting "master@{yesterday}-gdeadbeef" with the same
logic and format is misleading; "master@{yesterday}" may be the
closest ancestor of commit deadbeef, but that means it does
_not_ contain the fix. When walking ref-log, we want it the
other way around: "find the earliest descendant among the
entries in ref-log for a particular branch".
The internal logic for doing that may be somewhat different and
I suspect you may not be able to share much code with the
existing logic..
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html