Thomas Rast <> writes:

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

The machinery the follow uses simplifies the history with dynamic
pathspec correctly (in a simple history, at least), but the output
is coupled too strongly to the traversal. If you collect all the
revs you will show first, reverse them and then try to show (which
is what --reverse essentially is), the dynamic pathspec used for
each rev is long gone.

Perhaps we should make --follow mutually incompatible with
problematic options (I suspect --reverse is not the only case) at
the command line parser level to avoid hurting users.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to