On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote: > Lukas Fleischer <git@xxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html