From: John Keeping <john@keeping.me.uk>
Date: Tue, 02 Jul 2013 10:41:19 GMT
Subject: Re: --follow is ignored when used with --reverse
Message-ID: <20130702104119.GB9161@serenity.lan>
In-Reply-To: <87vc4t9tn5.fsf@linux-k42r.v.cablecom.net>

On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:
> Lukas Fleischer <git@cryptocrack.de> writes:
> 
> > On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
> [...]
> >>     $ git log --oneline --follow builtin/clone.c | wc -l
> >>     125
> >>     $ git log --oneline --follow --reverse builtin/clone.c | wc -l
> >>     3
> >
> > I just wanted to point out that it works fine when specifying the *original*
> > file name (which kind of makes sense given that everything is done in reverse
> > order):
> [...]
> > However, that also doesn't seem to work for builtin/clone.c:
> >
> >     $ git log --oneline --follow --reverse -- builtin-clone.c | wc -l
> >     65
> 
> I'm pretty sure that is simply because --follow iis a horrible hack,
> known to be broken in many ways.  I have it on my longer-term todo list
> to unify it with -L -M, which already does the Right Thing (more
> generally, not in the --reverse interaction, which it never occurred to
> me I should check).

Interesting... this tells me that --reverse doesn't work the way I
thought it did (although without any real evidence).  Given how
--reverse interacts with other options (like --max-count), I assumed it
would generate the commit list first and then simply reverse it before
display but it seems that this isn't what happens with --follow.

I guess that makes sense to avoid calculating the diff twice but I
suspect we have to pay that price to get correct output.