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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html