Re: [PATCH] First cut at libifying revlist generation

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> 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.