--follow is ignored when used with --reverse

Hello!

This [has been reported][1] to this list about half a year ago but with no response so I'm not even sure if it's been acknowledged as bug.

  [1]: http://marc.info/?l=git&m=135215709307126&q=raw

When I use `git log --follow file` all is OK, but once I add `--reverse` to it, it no longer follows the file beyond renames.

This makes it hard to query for when the file was really added, which I was trying to achieve with

    $ git -1 --reverse --follow several_times_renamed_file

Is this going to be fixed?

Thanks, aL.

On 2013-05-24 01:23, Alois Mahdal wrote:

I see that this list is **really** busy---my question got lost as a needle in an ocean.. :-) Immediately.

Maybe I should record an incident?

Could anyone point me in the right direction?  Just say the word! :)

aL.

Alois Mahdal wrote:

Yes, this is a bug. However, it is not at all easy to fix; so I would recommend that you contribute a documentation patch/ failing test for now (hint: patch emails get more attention that non-patch ones ;)

On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:

In my testing it actually seems to be worse than that.  In git.git:

    $ git log --oneline builtin/clone.c | wc -l
    99
    $ git log --oneline --reverse builtin/clone.c | wc -l
    99
    $ git log --oneline --follow builtin/clone.c | wc -l
    125
    $ git log --oneline --follow --reverse builtin/clone.c | wc -l
    3

So the combination of --reverse and --follow appears to have lost the majority of the commits!

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

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

    $ git init >/dev/null
    $ echo foo >a && git add a && git commit -m first
    [master (root-commit) 3631134] first
     1 file changed, 1 insertion(+)
     create mode 100644 a
    $ echo bar >b && git add b && git commit -m second
    [master 7772184] second
     1 file changed, 1 insertion(+)
     create mode 100644 b
    $ git mv b c && git commit -m third
    [master 0275097] third
     1 file changed, 0 insertions(+), 0 deletions(-)
     rename b => c (100%)
    $ git log --oneline --follow --reverse -- c
    0275097 third
    $ git log --oneline --follow --reverse -- b
    7772184 second
    0275097 third

However, that also doesn't seem to work for builtin/clone.c:

    $ git log --oneline --follow --reverse -- builtin-clone.c | wc -l
    65

Lukas Fleischer <git@cryptocrack.de> writes:

[...]

[...]

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

On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:

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.

Thomas Rast <trast@inf.ethz.ch> writes:

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.

Am 5/24/2013 1:23, schrieb Alois Mahdal:

Assuming you meant 'git log -1 ...' or similar. It won't do what you think it would do because:

* -1 is a revision traversal options.

* --reverse is an "output" option.

This means: First, revisions are collected, at which point -1 is honored. Second, the revisions found are listed in --reverse order.

When you have only one revision in the list, the output is the same with or without --reverse ;-)

-- Hannes