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

-- 
Alois Mahdal

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

[...]

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

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

Alois Mahdal wrote:

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.

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:

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

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:

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

quoted

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

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

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

So the combination of --reverse and --follow appears to have lost the
majority of the commits!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

...query for when the file was really added,
which I was trying to achieve with

    $ git -1 --reverse --follow several_times_renamed_file

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