# --follow is ignored when used with --reverse 9 messages from 2013-05-23 to 2013-07-02. Participants: Alois Mahdal, alois.mahdal.1-ndmail@zxcvb.cz, Ramkumar Ramachandra, John Keeping, Lukas Fleischer, Thomas Rast, Johannes Sixt, Junio C Hamano. Thread: https://gitlist.dev/t/33914 ## Alois Mahdal, 2013-05-23 23:23 Subject: --follow is ignored when used with --reverse Message-ID: <20130524012324.295dec77@hugo.daonet.home> URL: https://gitlist.dev/e/20130524012324.295dec77%40hugo.daonet.home ``` 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 ``` ## alois.mahdal.1-ndmail@zxcvb.cz, 2013-07-02 08:56 Subject: Re: --follow is ignored when used with --reverse Message-ID: <8c83f60d8eb4b7aaf4686f065e49ac93@zxcvb.cz> URL: https://gitlist.dev/e/8c83f60d8eb4b7aaf4686f065e49ac93%40zxcvb.cz In-Reply-To: <20130524012324.295dec77@hugo.daonet.home> ``` 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 ``` ## Ramkumar Ramachandra, 2013-07-02 09:12 Subject: Re: --follow is ignored when used with --reverse Message-ID: URL: https://gitlist.dev/e/CALkWK0ngwvQzL1cMGL5pWJoJHLYBHV2kUU%3Di3YiWt5V_uVLz7A%40mail.gmail.com In-Reply-To: <20130524012324.295dec77@hugo.daonet.home> ``` 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 ;) ``` ## John Keeping, 2013-07-02 09:19 Subject: Re: --follow is ignored when used with --reverse Message-ID: <20130702091936.GA9161@serenity.lan> URL: https://gitlist.dev/e/20130702091936.GA9161%40serenity.lan In-Reply-To: <20130524012324.295dec77@hugo.daonet.home> ``` 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! ``` ## Lukas Fleischer, 2013-07-02 09:38 Subject: Re: --follow is ignored when used with --reverse Message-ID: <20130702093842.GA4353@blizzard> URL: https://gitlist.dev/e/20130702093842.GA4353%40blizzard In-Reply-To: <20130702091936.GA9161@serenity.lan> ``` 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 ``` ## Thomas Rast, 2013-07-02 09:51 Subject: Re: --follow is ignored when used with --reverse Message-ID: <87vc4t9tn5.fsf@linux-k42r.v.cablecom.net> URL: https://gitlist.dev/e/87vc4t9tn5.fsf%40linux-k42r.v.cablecom.net In-Reply-To: <20130702093842.GA4353@blizzard> ``` 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. 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 ``` ## John Keeping, 2013-07-02 10:41 Subject: Re: --follow is ignored when used with --reverse Message-ID: <20130702104119.GB9161@serenity.lan> URL: https://gitlist.dev/e/20130702104119.GB9161%40serenity.lan In-Reply-To: <87vc4t9tn5.fsf@linux-k42r.v.cablecom.net> ``` On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote: > 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. 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. ``` ## Johannes Sixt, 2013-07-02 11:20 Subject: Re: --follow is ignored when used with --reverse Message-ID: <51D2B781.7000906@viscovery.net> URL: https://gitlist.dev/e/51D2B781.7000906%40viscovery.net In-Reply-To: <20130524012324.295dec77@hugo.daonet.home> ``` 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 ``` ## Junio C Hamano, 2013-07-02 19:11 Subject: Re: --follow is ignored when used with --reverse Message-ID: <7v38rw93pp.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v38rw93pp.fsf%40alter.siamese.dyndns.org In-Reply-To: <87vc4t9tn5.fsf@linux-k42r.v.cablecom.net> ``` 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. ```