All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: Martin von Zweigbergk <martinvonz@google.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Bug in `git branch --delete main` when on other orphan branch
Date: Tue, 1 Nov 2022 16:12:06 -0400	[thread overview]
Message-ID: <Y2F9lkCWf/2rjT2E@nand.local> (raw)
In-Reply-To: <Y2DxxZAFbN8juHY6@coredump.intra.peff.net>

On Tue, Nov 01, 2022 at 06:15:33AM -0400, Jeff King wrote:
> On Fri, Oct 28, 2022 at 10:46:37PM -0700, Martin von Zweigbergk wrote:
>
> > I did this:
> > git init test
> > cd test
> > echo a > file
> > git add file
> > git commit -m a
> > git checkout --orphan other
> > git branch --delete main
> >
> > The last command fails with:
> > fatal: Couldn't look up commit object for HEAD
> >
> > That's a bug, right? I can of course work around it with `rm
> > .git/refs/heads/main`.
>
> Sort of. This is part of the "is the thing we are deleting merged into
> HEAD" check. It tries to look up the HEAD and calls die() when it can't.
> The more correct thing, I think, would be for it to just return "nope,
> there is no HEAD so nothing is merged into it".

Yeah, I think that it's fair to call being unable to find HEAD in 'git
branch -d' when we are detached a bug. Indeed, if we can't find a HEAD,
then that's fine (there is just nothing merged into it, as you note).

> And in that case I think the HEAD check calling die() is actively doing
> the wrong thing, and would prevent an otherwise successful deletion.
>
> The fix might be as simple as:
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 15be0c03ef..f6ff9084c8 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -235,11 +235,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
>  	}
>  	branch_name_pos = strcspn(fmt, "%");
>
> -	if (!force) {
> +	if (!force)
>  		head_rev = lookup_commit_reference(the_repository, &head_oid);
> -		if (!head_rev)
> -			die(_("Couldn't look up commit object for HEAD"));
> -	}
>
>  	for (i = 0; i < argc; i++, strbuf_reset(&bname)) {
>  		char *target = NULL;
>
> as the later code seems to do the right thing with the NULL head_rev. It
> would definitely need more careful investigation (and tests!) to confirm
> that, though.

Yeah, that looks reasonable to me. Presumably we want a small test, as
well, but I doubt that is any more complicated than:

--- 8< ---
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 7f605f865b..6ace22f7ce 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -279,6 +279,14 @@ test_expect_success 'git branch -M and -C fail on detached HEAD' '
 	test_cmp expect err
 '

+test_expect_success 'git branch -d on detached HEAD' '
+	test_when_finished "git checkout main && git branch -D other" &&
+	git branch other &&
+	git checkout --orphan orphan &&
+	test_must_fail git branch -d other 2>err &&
+	grep "not fully merged" err
+'
+
 test_expect_success 'git branch -v -d t should work' '
 	git branch t &&
 	git rev-parse --verify refs/heads/t &&
--- >8 ---

I'm happy to wrap all of that up into a patch, and equally happy for you
to do so (feel free to forge my S-o-b here if you do).

Thanks,
Taylor

  parent reply	other threads:[~2022-11-01 20:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-29  5:46 Bug in `git branch --delete main` when on other orphan branch Martin von Zweigbergk
2022-11-01 10:15 ` Jeff King
2022-11-01 15:31   ` Martin von Zweigbergk
2022-11-01 20:12   ` Taylor Blau [this message]
2022-11-01 20:14     ` Bug in `git branch --delete main` when on other orphan brancht Taylor Blau
2022-11-01 21:45       ` Jeff King
2022-11-02  0:59         ` Taylor Blau
2022-11-01 20:32     ` [PATCH] branch: gracefully handle '-d' on detached HEAD Taylor Blau
2022-11-02  5:27       ` [PATCH v2] branch: gracefully handle '-d' on orphan HEAD Jeff King
2022-11-04  1:26         ` Rubén Justo
2022-11-04  5:36           ` Jeff King
2022-11-06 22:22             ` Rubén Justo

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=Y2F9lkCWf/2rjT2E@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martinvonz@google.com \
    --cc=peff@peff.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.