# Possible bug with argument parsing in git blame 5 messages from 2010-05-17 to 2010-05-24. Participants: Debayan Banerjee, Jeff King. Thread: https://gitlist.dev/t/23826 ## Debayan Banerjee, 2010-05-17 10:21 Subject: Possible bug with argument parsing in git blame Message-ID: URL: https://gitlist.dev/e/AANLkTikn1-Ua6G7eAc8UD8DJx0vpc-5-BOoxsi2mx2BC%40mail.gmail.com ``` debayan@deep-blur:~/testrepo$ git blame 22621a32..8486802f -- dir/subdir/newsubdir/b 81531975 b (debayan 2010-05-13 15:32:17 +0530 1) four 81531975 b (debayan 2010-05-13 15:32:17 +0530 2) five d700ac9c b (debayan 2010-05-13 15:33:27 +0530 3) blah 2656ab56 b (debayan 2010-05-13 15:33:34 +0530 4) bleh d0c6e851 b (debayan 2010-05-13 15:42:21 +0530 5) foo 7bf5510e b (debayan 2010-05-13 15:42:53 +0530 6) yo c4515289 b (debayan 2010-05-13 15:43:10 +0530 7) lala a257c7e4 b (debayan 2010-05-13 16:03:46 +0530 8) yes ed8e4601 b (debayan 2010-05-13 16:03:55 +0530 9) np e96d14bf dir/subdir/newsubdir/b (debayan 2010-05-13 16:05:05 +0530 10) yo dace00d1 dir/subdir/newsubdir/b (debayan 2010-05-13 16:05:11 +0530 11) boye 8486802f dir/subdir/newsubdir/b (debayan 2010-05-13 16:07:51 +0530 12) what? debayan@deep-blur:~/testrepo$ git blame 22621a32..8486802f dir/subdir/newsubdir/b fatal: cannot stat path 22621a32..8486802f: No such file or directory The only difference between the first and the second command is the "--" separator. Is this normal behaviour? -- Debayan Banerjee Software Engineer ``` ## Jeff King, 2010-05-23 08:00 Subject: Re: Possible bug with argument parsing in git blame Message-ID: <20100523080002.GB24598@coredump.intra.peff.net> URL: https://gitlist.dev/e/20100523080002.GB24598%40coredump.intra.peff.net In-Reply-To: ``` On Mon, May 17, 2010 at 03:51:18PM +0530, Debayan Banerjee wrote: > debayan@deep-blur:~/testrepo$ git blame 22621a32..8486802f -- > dir/subdir/newsubdir/b > > 81531975 b (debayan 2010-05-13 15:32:17 +0530 1) four > 81531975 b (debayan 2010-05-13 15:32:17 +0530 2) five > d700ac9c b (debayan 2010-05-13 15:33:27 +0530 3) blah > 2656ab56 b (debayan 2010-05-13 15:33:34 +0530 4) bleh > d0c6e851 b (debayan 2010-05-13 15:42:21 +0530 5) foo > 7bf5510e b (debayan 2010-05-13 15:42:53 +0530 6) yo > c4515289 b (debayan 2010-05-13 15:43:10 +0530 7) lala > a257c7e4 b (debayan 2010-05-13 16:03:46 +0530 8) yes > ed8e4601 b (debayan 2010-05-13 16:03:55 +0530 9) np > e96d14bf dir/subdir/newsubdir/b (debayan 2010-05-13 16:05:05 +0530 10) yo > dace00d1 dir/subdir/newsubdir/b (debayan 2010-05-13 16:05:11 +0530 11) boye > 8486802f dir/subdir/newsubdir/b (debayan 2010-05-13 16:07:51 +0530 12) what? > > debayan@deep-blur:~/testrepo$ git blame 22621a32..8486802f > dir/subdir/newsubdir/b > fatal: cannot stat path 22621a32..8486802f: No such file or directory > > The only difference between the first and the second command is the > "--" separator. Is this normal behaviour? I can't reproduce the problem here. For example, in git.git, both of the following produce the same output: git blame HEAD~5..HEAD~3 alloc.c git blame HEAD~5..HEAD~3 -- alloc.c Can you provide the exact set of commands to replicate your repository state and show the failure? Also, I tested with the current 'master'. Are you using an older version of git? -Peff ``` ## Jeff King, 2010-05-23 20:08 Subject: Re: Possible bug with argument parsing in git blame Message-ID: <20100523200853.GA23377@coredump.intra.peff.net> URL: https://gitlist.dev/e/20100523200853.GA23377%40coredump.intra.peff.net In-Reply-To: ``` On Sun, May 23, 2010 at 07:22:41PM +0530, Debayan Banerjee wrote: > > I can't reproduce the problem here. For example, in git.git, both of the > > following produce the same output: > > > >  git blame HEAD~5..HEAD~3 alloc.c > >  git blame HEAD~5..HEAD~3 -- alloc.c > > It seems to happen only if the path has '/' in it. For example alloc.c > will be parsed fine, but dir/alloc.c wont. Sorry, I still can't reproduce with: mkdir repo && cd repo && git init mkdir subdir commit() { echo content >>subdir/file git add subdir/file git commit -m foo } commit; commit; commit; commit; commit git blame HEAD~3..HEAD~1 subdir/file >no-dash && git blame HEAD~3..HEAD~1 -- subdir/file >dash && diff no-dash dash && echo ok So there must be some difference between your setup and my test case. Can you give more details? -Peff PS I tested on a variety of git versions back to v1.5.5, and I couldn't trigger the problem, so I don't think it is a version issue. ``` ## Debayan Banerjee, 2010-05-24 06:17 Subject: Re: Possible bug with argument parsing in git blame Message-ID: URL: https://gitlist.dev/e/AANLkTikEiRuitD7lrZQIaOruCBrL1Vu5K74Y4wGoiC1z%40mail.gmail.com In-Reply-To: <20100523200853.GA23377@coredump.intra.peff.net> ``` On 24 May 2010 01:38, Jeff King wrote: > On Sun, May 23, 2010 at 07:22:41PM +0530, Debayan Banerjee wrote: > >> > I can't reproduce the problem here. For example, in git.git, both of the >> > following produce the same output: >> > I used master too. The test cases you provided work fine for me too. It also seems that '/' is not a problem. I tested myself with some combinations and i could not reproduced the bug. But the strange behaviour i reported with my particular case still exists. My repo structure can be cloned from http://github.com/debayan/git-blame-test . -- Debayan Banerjee Software Engineer ``` ## Jeff King, 2010-05-24 06:46 Subject: Re: Possible bug with argument parsing in git blame Message-ID: <20100524064641.GA10858@coredump.intra.peff.net> URL: https://gitlist.dev/e/20100524064641.GA10858%40coredump.intra.peff.net In-Reply-To: ``` On Mon, May 24, 2010 at 11:47:02AM +0530, Debayan Banerjee wrote: > I used master too. The test cases you provided work fine for me too. > It also seems that '/' is not a problem. I tested myself with some > combinations and i could not reproduced the bug. But the strange > behaviour i reported with my particular case still exists. My repo > structure can be cloned from http://github.com/debayan/git-blame-test > . OK, I see what is happening. The issue is that you are blaming a file from some revision, but that file doesn't exist in the working tree. You can recreate it with: git init echo contents >>foo && git add foo && git commit -m one echo contents >>foo && git add foo && git commit -m two echo contents >>foo && git add foo && git commit -m three git mv foo bar && git commit -m moved Now "git blame HEAD~2..HEAD~1 -- foo" will work, but "git blame HEAD~2..HEAD~1 foo" will not work. This is as expected. When parsing revision/filename combinations, if there is no explicit "--" separator, then we only allow filenames if the file exists in the working tree. The idea is to prevent typos. For example, in the same repo: git bar ;# works, we have bar in the working tree git log foo ;# complains, foo is not a revision and not a file, so # maybe a typo git log -- foo ;# works, filters on foo. The "--" makes it explicit Things are a little bit funny with blame because: 1. It should take exactly one filename, so it doesn't have this ambiguity. 2. The error message isn't very helpful. I think this is because blame actually accepts several different combinations (like " ", and it ends up confused. I would be tempted to improve this, but I think (1) may no longer be the case soon. As I understand it, some of Bo Yang's work in this area may mean that blame will soon accept multiple files, and the argument parsing may change. -Peff ```