git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2 1/2] rev-parse: exit with non-zero status if ref@{n} is not valid.

From
Jon Seymour <jon.seymour@gmail.com>
Date
Aug 23, 2010, 23:11 UTC
Message-ID
<1282605103-8320-2-git-send-email-jon.seymour@gmail.com>
In-Reply-To
<7vr5hp1e6i.fsf@alter.siamese.dyndns.org>
>From Junio's e-mail:
"The current behaviour of ref@{...} syntax parser is suboptimal:
    $ git rev-parse --verify jch@{99999} && echo true
    warning: Log for 'jch' only has 1368 entries.
    cfb88e9a8d4926b0011ae2dd67e1f57a98f4b768
    true

It even knows that it is running off the cut-off point; it should just cause the caller to notice that fact. I don't think changing it to error out should cause any harm to existing callers."

With this change:
   $ git rev-parse --verify jch@{99999} || echo false
   fatal: Log for 'jch' only has 1368 entries.
   false
   $ git rev-parse jch@{99999} || echo false
   fatal: Log for 'jch' only has 1368 entries.
   false
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
 sha1_name.c |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 4af94fa..d40ae48 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -342,7 +342,7 @@ static int get_sha1_1(const char *name, int len, unsigned char *sha1);
 
 static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 {
-	static const char *warning = "warning: refname '%.*s' is ambiguous.\n";
+	static const char *warn_msg = "warning: refname '%.*s' is ambiguous.";
 	char *real_ref = NULL;
 	int refs_found = 0;
 	int at, reflog_len;
@@ -390,7 +390,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 		return -1;
 
 	if (warn_ambiguous_refs && refs_found > 1)
-		fprintf(stderr, warning, len, str);
+		fprintf(stderr, warn_msg, len, str);
 
 	if (reflog_len) {
 		int nth, i;
@@ -426,14 +426,16 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 		if (read_ref_at(real_ref, at_time, nth, sha1, NULL,
 				&co_time, &co_tz, &co_cnt)) {
 			if (at_time)
-				fprintf(stderr,
-					"warning: Log for '%.*s' only goes "
-					"back to %s.\n", len, str,
+				warning("Log for '%.*s' only goes "
+					"back to %s.", len, str,
 					show_date(co_time, co_tz, DATE_RFC2822));
-			else
-				fprintf(stderr,
-					"warning: Log for '%.*s' only has "
-					"%d entries.\n", len, str, co_cnt);
+			else {
+				free(real_ref);
+				die("Log for '%.*s' only has %d entries.",
+						len,
+						str,
+						co_cnt);
+			}
 		}
 	}
 
-- 
1.7.2.1.99.geab11
Previous: Jon SeymourNext: Jonathan Nieder
Message 12 of 20 in “RFD: should git rev-parse exit with non-zero status if ref@{n} is not valid?”
  1. Jon SeymourAug 18, 2010
  2. Jon SeymourAug 18, 2010
  3. Junio C HamanoAug 18, 2010
  4. Jon SeymourAug 18, 2010
  5. 0/4 rev-parse: improve reporting of invalid log referencesJon Seymour, Aug 21, 2010
  6. 1/4 rev-parse: exit with non-zero status if ref@{n} is not valid.Jon Seymour, Aug 21, 2010
  7. 2/4 rev-parse: suppress duplicate log limit exceeded message.Jon Seymour, Aug 21, 2010
  8. Junio C HamanoAug 22, 2010
  9. Jon SeymourAug 23, 2010
  10. Junio C HamanoAug 23, 2010
  11. 0/2 rev-parse: strengthen validation of ref@{n} referencesJon Seymour, Aug 23, 2010
  12. 1/2 rev-parse: exit with non-zero status if ref@{n} is not valid.Jon Seymour, Aug 23, 2010
  13. Jonathan NiederAug 24, 2010
  14. 0/3 rev-parse: strengthen validation of ref@{n} referencesJon Seymour, Aug 24, 2010
  15. 1/3 rev-parse: exit with non-zero status if ref@{n} is not valid.Jon Seymour, Aug 24, 2010
  16. 2/3 sha1_name.c: use warning in preference to fprintf(stderrJon Seymour, Aug 24, 2010
  17. 3/3 rev-parse: tests git rev-parse --verify master@{n}, for various nJon Seymour, Aug 24, 2010
  18. 2/2 rev-parse: tests git rev-parse --verify master@{n}, for various nJon Seymour, Aug 23, 2010
  19. 3/4 rev-parse: introduce get_sha1_gentlyJon Seymour, Aug 21, 2010
  20. 4/4 rev-parse: tests that git rev-parse --verify master@{n}Jon Seymour, Aug 21, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.