Revision af13cdf298b927d171a58ec30c885d2a9c9bf727 authored by Linus Torvalds on 28 October 2005, 19:41:49 UTC, committed by Junio C Hamano on 28 October 2005, 21:25:05 UTC
This does two things: - we don't allow "." and ".." as components of a refname. Thus get_sha1() will not accept "./refname" as being the same as "refname" any more. - git-rev-parse stops doing revision translation after seeing a pathname, to match the brhaviour of all the tools (once we see a pathname, everything else will also be parsed as a pathname). Basically, if you did git log * and "gitk" was somewhere in the "*", we don't want to replace the filename "gitk" with the SHA1 of the branch with the same name. Of course, if there is any change of ambiguity, you should always use "--" to make it explicit what are filenames and what are revisions, but this makes the normal cases sane. The refname rule also means that instead of the "--", you can do the same thing we're used to doing with filenames that start with a slash: use "./filename" instead, and now it's a filename, not an option (and not a revision). So "git log ./*.c" is now actually a perfectly valid thing to do, even if the first C-file might have the same name as a branch. Trivial test: git-rev-parse gitk ./gitk gitk should output something like 9843c3074dfbf57117565f6b7c93e3e6812857ee ./gitk gitk where the "./gitk" isn't seen as a revision, and the second "gitk" is a filename simply because we've seen filenames already, and thus stopped doing revision parsing. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
1 parent 41f222e
File | Mode | Size |
---|---|---|
.gitignore | -rw-r--r-- | 58 bytes |
changelog | -rw-r--r-- | 2.1 KB |
compat | -rw-r--r-- | 2 bytes |
control | -rw-r--r-- | 1.1 KB |
copyright | -rw-r--r-- | 978 bytes |
docs | -rw-r--r-- | 7 bytes |
git-core.doc-base | -rw-r--r-- | 237 bytes |
git-core.files | -rw-r--r-- | 5 bytes |
git-tk.files | -rw-r--r-- | 72 bytes |
rules | -rwxr-xr-x | 2.1 KB |
Computing file changes ...