path: root/rev-parse.c
diff options
authorLinus Torvalds <>2005-10-28 19:41:49 (GMT)
committerJunio C Hamano <>2005-10-28 21:25:05 (GMT)
commitaf13cdf298b927d171a58ec30c885d2a9c9bf727 (patch)
treec297ec95c45be168d4cdb93fe417d8b8d62aded9 /rev-parse.c
parent41f222e87a9062833712367d66114cae90b3769a (diff)
Be more careful about reference parsing
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 <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'rev-parse.c')
1 files changed, 1 insertions, 0 deletions
diff --git a/rev-parse.c b/rev-parse.c
index adfc68c..169d0cc 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -292,6 +292,7 @@ int main(int argc, char **argv)
if (verify)
die("Needed a single revision");
+ as_is = 1;