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

Thomas Rast [off-list ref] writes:

Lukas Fleischer [off-list ref] writes:

quoted

On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:

[...]

quoted

quoted

    $ 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):

[...]

quoted

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.