Re: git and time
- From
Junio C Hamano <junkio@cox.net>
- Date
- Sep 30, 2006, 23:04 UTC
- Message-ID
- <7vd59d7y8v.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.64.0609301033460.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
Show 18 quoted lines
> On Sat, 30 Sep 2006, Junio C Hamano wrote: > >> Shawn Pearce <spearce@spearce.org> 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..