On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:
> Lukas Fleischer <g...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to