* Possible bug with argument parsing in git blame
@ 2010-05-17 10:21 Debayan Banerjee
2010-05-23 8:00 ` Jeff King
0 siblings, 1 reply; 5+ messages in thread
From: Debayan Banerjee @ 2010-05-17 10:21 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug with argument parsing in git blame
2010-05-17 10:21 Possible bug with argument parsing in git blame Debayan Banerjee
@ 2010-05-23 8:00 ` Jeff King
[not found] ` <AANLkTinMlvmOneGgkIqxE8qWlhoOlqgALl-YHprqPI6h@mail.gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Jeff King @ 2010-05-23 8:00 UTC (permalink / raw
To: Debayan Banerjee; +Cc: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug with argument parsing in git blame
[not found] ` <AANLkTinMlvmOneGgkIqxE8qWlhoOlqgALl-YHprqPI6h@mail.gmail.com>
@ 2010-05-23 20:08 ` Jeff King
2010-05-24 6:17 ` Debayan Banerjee
0 siblings, 1 reply; 5+ messages in thread
From: Jeff King @ 2010-05-23 20:08 UTC (permalink / raw
To: Debayan Banerjee; +Cc: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug with argument parsing in git blame
2010-05-23 20:08 ` Jeff King
@ 2010-05-24 6:17 ` Debayan Banerjee
2010-05-24 6:46 ` Jeff King
0 siblings, 1 reply; 5+ messages in thread
From: Debayan Banerjee @ 2010-05-24 6:17 UTC (permalink / raw
To: Jeff King; +Cc: git
On 24 May 2010 01:38, Jeff King <peff@peff.net> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug with argument parsing in git blame
2010-05-24 6:17 ` Debayan Banerjee
@ 2010-05-24 6:46 ` Jeff King
0 siblings, 0 replies; 5+ messages in thread
From: Jeff King @ 2010-05-24 6:46 UTC (permalink / raw
To: Debayan Banerjee; +Cc: git
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 "<path>
<rev>", 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-05-24 6:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-17 10:21 Possible bug with argument parsing in git blame Debayan Banerjee
2010-05-23 8:00 ` Jeff King
[not found] ` <AANLkTinMlvmOneGgkIqxE8qWlhoOlqgALl-YHprqPI6h@mail.gmail.com>
2010-05-23 20:08 ` Jeff King
2010-05-24 6:17 ` Debayan Banerjee
2010-05-24 6:46 ` Jeff King
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).