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

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 23, 2006, 16:19 UTC
Message-ID: <Pine.LNX.4.64.0604230906370.3701@g5.osdl.org>
In-Reply-To: <17483.27938.890830.375324@cargo.ozlabs.ibm.com>

On Sun, 23 Apr 2006, Paul Mackerras wrote:

Show 8 quoted lines

>
> 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