--follow is ignored when used with --reverse

--follow is ignored when used with --reverse

[Alois Mahdal]

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

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

[alois.mahdal.1-ndmail]

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

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

[Ramkumar Ramachandra]

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

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

[John Keeping]

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!

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

[Lukas Fleischer]

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

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

[Thomas Rast]

Lukas Fleischer <git@cryptocrack.de> 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).

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

[John Keeping]

On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:
> Lukas Fleischer <git@cryptocrack.de> 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.

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

[Johannes Sixt]

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

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

[Junio C Hamano]

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

> Lukas Fleischer <git@cryptocrack.de> 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.