git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Chris Down <chris@chrisdown.name>
To: git@vger.kernel.org
Cc: Christian Couder <chriscool@tuxfamily.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] bisect--helper: warn if we are assuming an unlikely pathspec
Date: Sun, 1 May 2022 13:29:14 +0100	[thread overview]
Message-ID: <Ym59GmfWpCSV9Bqr@chrisdown.name> (raw)

Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour to consider invalid oids as pathspecs
again, as in the old shell implementation.

While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:

    $ git bisect start d93ff48803f0 v6.3
    $

...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.

It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.

While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.

In order to avoid this, emit a warning when we are assuming an argument
is a pathspec, but no such path exists in the checkout and this doesn't
look like a pathspec according to looks_like_pathspec:

    $ git bisect start d93ff48803f0 v6.3
    warning: assuming 'v6.3' is a path
    $

If the filename is after the double dash, assume the user knows what
they're doing, just like with other git commands.

Signed-off-by: Chris Down <chris@chrisdown.name>
---
 builtin/bisect--helper.c    |  4 ++++
 cache.h                     |  1 +
 setup.c                     |  2 +-
 t/t6030-bisect-porcelain.sh | 18 ++++++++++++++++++
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index 8b2b259ff0..30a73e2a7d 100644
--- a/builtin/bisect--helper.c
+++ b/builtin/bisect--helper.c
@@ -682,6 +682,10 @@ static enum bisect_error bisect_start(struct bisect_terms *terms, const char **a
 			die(_("'%s' does not appear to be a valid "
 			      "revision"), arg);
 		} else {
+			if (!has_double_dash &&
+			    !looks_like_pathspec(arg) &&
+			    !check_filename(NULL, arg))
+				warning(_("assuming '%s' is a path"), arg);
 			break;
 		}
 	}
diff --git a/cache.h b/cache.h
index 6226f6a8a5..bae92859a3 100644
--- a/cache.h
+++ b/cache.h
@@ -648,6 +648,7 @@ void verify_filename(const char *prefix,
 		     int diagnose_misspelt_rev);
 void verify_non_filename(const char *prefix, const char *name);
 int path_inside_repo(const char *prefix, const char *path);
+int looks_like_pathspec(const char *arg);
 
 #define INIT_DB_QUIET 0x0001
 #define INIT_DB_EXIST_OK 0x0002
diff --git a/setup.c b/setup.c
index a7b36f3ffb..bafbfb0d5e 100644
--- a/setup.c
+++ b/setup.c
@@ -208,7 +208,7 @@ static void NORETURN die_verify_filename(struct repository *r,
  * but which look sufficiently like pathspecs that we'll consider
  * them such for the purposes of rev/pathspec DWIM parsing.
  */
-static int looks_like_pathspec(const char *arg)
+int looks_like_pathspec(const char *arg)
 {
 	const char *p;
 	int escaped = 0;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 5382e5d216..2ea50f4ba4 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -1025,4 +1025,22 @@ test_expect_success 'bisect visualize with a filename with dash and space' '
 	git bisect visualize -p -- "-hello 2"
 '
 
+test_expect_success 'bisect warning on implicit enoent pathspec' '
+	git bisect reset &&
+	git bisect start "$HASH4" doesnotexist 2>output &&
+	grep -F "assuming '\''doesnotexist'\'' is a path" output
+'
+
+test_expect_success 'bisect fatal on implicit enoent pathspec with dash' '
+	git bisect reset &&
+	test_must_fail git bisect start "$HASH4" doesnotexist -- dne2 2>output &&
+	grep -F "'\''doesnotexist'\'' does not appear to be a valid revision" output
+'
+
+test_expect_success 'bisect no warning on explicit enoent pathspec' '
+	git bisect reset &&
+	git bisect start "$HASH4" -- doesnotexist 2>output &&
+	[ -z "$(cat output)" ]
+'
+
 test_done
-- 
2.36.0


             reply	other threads:[~2022-05-01 12:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01 12:29 Chris Down [this message]
2022-05-02  5:50 ` [PATCH] bisect--helper: warn if we are assuming an unlikely pathspec Bagas Sanjaya
2022-05-02  6:22   ` Junio C Hamano
2022-05-03 18:51     ` Chris Down

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=Ym59GmfWpCSV9Bqr@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).