Re: --follow is ignored when used with --reverse

From: John Keeping <john@keeping.me.uk>
Date: Jul 2, 2013, 10:41 UTC
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:

Show 23 quoted lines

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