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);
}
next 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).