Re: lstat() call in rev-parse.c

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 23 Apr 2006, Paul Mackerras wrote:
>
> Why does git-rev-parse do an lstat on some of its arguments, at line
> 345 of rev-parse.c, and die if the lstat fails?  It doesn't seem to do
> anything with the result.
> 
> The effect is that if you do "gitk a b", it works as long as a and b
> exist (as files or directories), but fails if they don't, and some
> users have found this confusing.

Because it's even _more_ common to do

	gitk v2.6.16

(in the git directory) and be very confused when that returns an empty 
history. 

So the rule is: if you don't give that "--", then we have to be able to 
confirm that the filenames are really files. Not a misspelled revision 
name, or a revision name that was correctly spelled, but for the wrong 
project, because you were in the wrong subdirectory ;)

And yes, this actually happened to me. I was demonstrating git before we 
did that fix, and I used the wrong tag-name, and gitk would think for a 
minute and them show "No commits selected" with no error, because 
"v2.6.16" didn't exist at that time, and it used the "tag-name" as a 
filename, and that filename didn't actually exist, so the number of 
commits that changed it was exactly zero.

So now, if you do "gitk v2.6.16" in the git directory, it will return a 
nice and understandable 

	Error reading commits: fatal: 'v2.6.16': No such file or directory

which is _exactly_ what you want. The only problem is that gitk will 
actually open the big window too, and the error window is small and can be 
non-obvious if the window manager hides it in some corner. So I actually 
think you should try to make the error window come up smack dab in front 
of the main gitk window and make the error clearer.

So the rules are simple:
 - the filenames are _always_ separated by "--"
 - we have a short-hand, which allows the "--" to be dropped iff it is 
   unambiguous

Where "unambiguous" means that
 - the revision name cannot possible be interpreted as a filename (we 
   don't check this part yet, but I think we should)
 - all filenames are obviously not revision names, since they not 
   only aren't valid revisions, they actually exist as files.

Otherwise, misspellings, typos, and thinkos result in total confusion.

		Linus