git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
Subject: Make git-rev-list and git-rev-parse argument parsing stricter
Date: Wed, 25 Jan 2006 17:00:37 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0601251655580.2644@evo.osdl.org> (raw)


If you pass it a filename without the "--" marker to separate it from
revision information and flags, we now require that the file in question
actually exists. This makes mis-typed revision information not be silently
just considered a strange filename.

With the "--" marker, you can continue to pass in filenames that do not
actually exists - useful for querying what happened to a file that you
no longer have in the repository.

[ All scripts should use the "--" format regardless, to make things
  unambiguous. So this change should not affect any existing tools ]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----

I hit this the hard way when I was showing off git at Linux.Conf.Au 
yesterday, and I asked for

	git log v2.6.14..v2.6.16

which silently did nothing at all. The reason? I don't actually have a 
v2.6.16, the most recent version is 2.6.16-rc1. So it thought 
v2.6.14..v2.6.16 was a _filename_.

Now, normally, if you use the "proper" format (with the -- delimeter to 
mark where filenames start), you'd never have this ambiguity. But without 
the "--", the way I decided that we should disambiguate things is to 
verify that any filename given with the ambiguous shorthand version 
actually exists.

Comments?

diff --git a/rev-list.c b/rev-list.c
index d060966..e00e6fc 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -844,8 +844,12 @@ int main(int argc, const char **argv)
 			arg++;
 			limited = 1;
 		}
-		if (get_sha1(arg, sha1) < 0)
+		if (get_sha1(arg, sha1) < 0) {
+			struct stat st;
+			if (lstat(arg, &st) < 0)
+				die("'%s': %s", arg, strerror(errno));
 			break;
+		}
 		commit = get_commit_reference(arg, sha1, flags);
 		handle_one_commit(commit, &list);
 	}
diff --git a/rev-parse.c b/rev-parse.c
index 0c951af..7abad35 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -154,6 +154,7 @@ int main(int argc, char **argv)
 	const char *prefix = setup_git_directory();
 	
 	for (i = 1; i < argc; i++) {
+		struct stat st;
 		char *arg = argv[i];
 		char *dotdot;
 	
@@ -293,6 +294,8 @@ int main(int argc, char **argv)
 		}
 		if (verify)
 			die("Needed a single revision");
+		if (lstat(arg, &st) < 0)
+			die("'%s': %s", arg, strerror(errno));
 		as_is = 1;
 		show_file(arg);
 	}

             reply	other threads:[~2006-01-25 22:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25 22:00 Linus Torvalds [this message]
2006-01-25 22:02 ` git-whatchanged: exit out early on errors Linus Torvalds
2006-01-25 22:40 ` Make git-rev-list and git-rev-parse argument parsing stricter Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0601251655580.2644@evo.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).