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

Re: Regression in 'git branch -m'?

From
Jeff King <peff@peff.net>
Date
Oct 6, 2017, 07:39 UTC
Message-ID
<20171006073913.yavdbdd3p3y5vjhd@sigill.intra.peff.net>
In-Reply-To
<20171005183303.f77dpkhs5ztxlmyv@sigill.intra.peff.net>
On Thu, Oct 05, 2017 at 02:33:03PM -0400, Jeff King wrote:
Show 11 quoted lines
> Looks like 31824d180d (branch: fix branch renaming not updating HEADs
> correctly, 2017-08-24). This is in v2.15.0-rc0, so we should figure it
> out before the upcoming release.
> 
> I didn't dig very far, but it looks like the branch name is important
> "foo" doesn't trigger the problem but "master/master" does. "master/foo"
> also does, but "foo/master" does not. So I suspect it's something about
> how resolve_ref handles the failure when it would not be able to create
> the ref because of the d/f conflict. So it's probably related to losing
> the RESOLVE_REF_READING in the final hunk of that patch. That's just a
> guess for now, though.

I got a chance to look at this again. I think the root of the problem is that resolve_ref() as it is implemented now is just totally unsuitable for asking the question "what does this symbolic link point to?".

Because you end up with either:
  1. If we pass RESOLVE_REF_READING, then we do not return the target
     refname for orphaned commits (which is why 31824d180d dropped it).
  2. If not, then we do not return the target refname for commits with
     names that are not available for writing. The d/f conflict here is
     one example, but there may be others.

So I think we need to teach resolve_ref() a new mode that's like "reading", but just follows the symref chain.

In the meantime, here's a test which shows off the regression.
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 3ac7ebf85f..503a88d029 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -117,6 +117,16 @@ test_expect_success 'git branch -m bbb should rename checked out branch' '
 	test_cmp expect actual
 '
 
+test_expect_success 'renaming checked out branch works with d/f conflict' '
+	test_when_finished "git branch -D foo/bar || git branch -D foo" &&
+	test_when_finished git checkout master &&
+	git checkout -b foo &&
+	git branch -m foo/bar &&
+	git symbolic-ref HEAD >actual &&
+	echo refs/heads/foo/bar >expect &&
+	test_cmp expect actual
+'
+
 test_expect_success 'git branch -m o/o o should fail when o/p exists' '
 	git branch o/o &&
 	git branch o/p &&

-Peff
Previous: Jeff KingNext: Jeff King
Message 3 of 14 in “Regression in 'git branch -m'?”
  1. Andreas KreyOct 5, 2017
  2. Jeff KingOct 5, 2017
  3. Jeff KingOct 6, 2017
  4. Jeff KingOct 6, 2017
  5. Junio C HamanoOct 6, 2017
  6. Jeff KingOct 6, 2017
  7. Jeff KingOct 6, 2017
  8. 1/2 t3308: create a real ref directory/file conflictJeff King, Oct 6, 2017
  9. 2/2 refs_resolve_ref_unsafe: handle d/f conflicts for writesJeff King, Oct 6, 2017
  10. Michael HaggertyOct 6, 2017
  11. Jeff KingOct 6, 2017
  12. Michael HaggertyOct 7, 2017
  13. Michael HaggertyNov 5, 2017
  14. Junio C HamanoOct 7, 2017

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.