Re: [PATCH] First cut at libifying revlist generation

From: Junio C Hamano <junkio@cox.net>
Date: Feb 27, 2006, 05:09 UTC
Message-ID: <7vy7zx1j6u.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0602261914270.22647@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 9 quoted lines

> On Sun, 26 Feb 2006, Junio C Hamano wrote:
>> 
>> I am clueless about the "limited = (list && list->next)" part,
>> but there is only one commit involved hence the test is false
>> with my testcase "git-rev-list --objects v1.0.0^0..v1.0.0"; I
>> think the old code said dotdot is a limited case.
>
> dotdot should insert _two_ commits onto the list - the positive and 
> the negative one.  Doesn't it?

Not really, because the second invocation of add_one_commit() says "I've seen that *commit*", which is correct. And the story is obviously the same if you used longhand "^v1.0.0^0 v1.0.0".

As a symbolic notation v1.0.0^0..v1.0.0 may not make much sense, but the point is "the other end says he has that commit object, but now he wants the tag we later attached to that commit object; let's list the objects we need to send him". This is what upload-pack does.

A bad consequence of not limiting is that:

	git-rev-list ^v1.0.0^0 v1.0.0 | tail -n 1

gives this commit ;-):

	e83c5163316f89bfbde7d9ab23ca2e25604af290

Argh.