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

Re: [PATCH v2] fetch: fix non-conflicting tags not being committed

From
Patrick Steinhardt <ps@pks.im>
Date
Nov 7, 2025, 14:07 UTC
Message-ID
<aQ39P0mAFqDGPYxS@pks.im>
In-Reply-To
<CAOLa=ZQpTqnCQs4=wcUwJOWy5mXiG4y_eTiFtPkS2uOk4U66Tw@mail.gmail.com>
On Fri, Nov 07, 2025 at 05:15:32AM -0800, Karthik Nayak wrote:
Show 30 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
> > On Thu, Nov 06, 2025 at 09:39:25AM +0100, Karthik Nayak wrote:
> > The following test demonstrates this behaviour:
> >
> > 	test_expect_success "fetch single branch without explicit tag option" '
> > 		git init source &&
> > 		git -C source commit --allow-empty --message common &&
> > 		git clone file://"$(pwd)"/source target &&
> > 		(
> > 			cd source &&
> > 			git commit --allow-empty --message discard-me &&
> > 			git tag discard-me &&
> > 			git commit --amend --allow-empty --message fetch-me &&
> > 			git tag fetch-me
> > 		) &&
> >
> > 		# The "discard-me" tag does not point into the history that we are
> > 		# about to fetch, so it should not have been created.
> > 		git -C target fetch origin &&
> > 		git -C target tag -l >actual &&
> > 		echo "fetch-me" >expect &&
> >
> > 		# But with "--tags" we instruct git-fetch(1) to fetch all tags, so we
> > 		# should now see it.
> > 		git -C target fetch origin --tags &&
> 
> Here, we don't really backfill, but rather we request all tags from the
> remote, hence we end up with the 'discard-me' tag. Not because of the
> diverged history. I also confirmed this by adding a breakpoint into the
> `backfill_tags()` function, while running this test.

Oh, exactly. But there's two fetches here: the first one only fetches "fetch-me" because we don't pass "--tags". The second one was simply as a demonstration that we would also fetch the other tag that doesn't point into our fetched history with "--tags".

I notice though that the first fetch forgot to `test_cmp`.
Show 35 quoted lines
> > 		git -C target tag -l >actual &&
> > 		cat >expect <<-\EOF &&
> > 		discard-me
> > 		fetch-me
> > 		EOF
> > 		test_cmp expect actual
> > 	'
> 
> But I was able to slightly modify the test to get the required affect:
> 
>   test_expect_success "backfill tags when providing a refspec" '
>   	git init source &&
>   	git -C source commit --allow-empty --message common &&
>   	git clone file://"$(pwd)"/source target &&
>   	(
>   	    cd source &&
>   	    git commit --allow-empty --message history &&
>   	    git tag history &&
>   	    git commit --allow-empty --message fetch-me &&
>   	    git tag fetch-me
>   	) &&
> 
>   	# The "history" tag is backfilled eventhough we requested
>   	# to only fetch the master
>   	git -C target fetch origin master:branch &&
>   	git -C target tag -l >actual &&
>   	cat >expect <<-\EOF &&
>   	fetch-me
>   	history
>   	EOF
>   	test_cmp expect actual
>   '
> 
> I will add this in. Thanks for the explanation, it really helped
> consolidate my understanding here.
Yup, that should work, as well.
Show 5 quoted lines
> >> diff --git a/builtin/fetch.c b/builtin/fetch.c
> >> index c7ff3480fb..d5aee5af10 100644
> >> --- a/builtin/fetch.c
> >> +++ b/builtin/fetch.c
> >> @@ -1686,6 +1686,42 @@ static void ref_transaction_rejection_handler(const char *refname,
[snip]
Show 21 quoted lines
> >> +	if (*transaction && !is_atomic) {
> >> +		struct ref_rejection_data data = {
> >> +			.conflict_msg_shown = 0,
> >> +			.remote_name = remote_name,
> >> +			.retcode = &retcode,
> >> +		};
> >> +
> >> +		ref_transaction_for_each_rejected_update(*transaction,
> >> +							 ref_transaction_rejection_handler,
> >> +							 &data);
> >> +
> >> +		ref_transaction_free(*transaction);
> >> +		*transaction = NULL;
> >> +	}
> >
> > Okay. Do we need to discern cases where this is called and we haven't
> > managed to even queue a single reference update?
> >
> 
> I don't see a reason. This is anyways a post-commit action, if there are
> no updates, there will be no rejections. So this will be a no-op.

I guess the question was rather whether we fear a negative consequence by trying to commit an empty transaction. The commit doesn't know to short-circuit empty transactions, so we'd still end up locking data even though we eventually end up doing nothing.

Thanks!
Patrick
Previous: Karthik NayakNext: Karthik Nayak
Message 9 of 54 in “fetch: fix non-conflicting tags not being committed”
  1. fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 3, 2025
  2. Eric SunshineNov 3, 2025
  3. Karthik NayakNov 3, 2025
  4. Justin ToblerNov 3, 2025
  5. fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 6, 2025
  6. Patrick SteinhardtNov 6, 2025
  7. Junio C HamanoNov 6, 2025
  8. Karthik NayakNov 7, 2025
  9. Patrick SteinhardtNov 7, 2025
  10. Karthik NayakNov 7, 2025
  11. Justin ToblerNov 6, 2025
  12. Karthik NayakNov 7, 2025
  13. 0/2 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 8, 2025
  14. 1/2 fetch: extract out reference committing logicKarthik Nayak, Nov 8, 2025
  15. Patrick SteinhardtNov 10, 2025
  16. Karthik NayakNov 10, 2025
  17. 2/2 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 8, 2025
  18. Patrick SteinhardtNov 10, 2025
  19. Karthik NayakNov 10, 2025
  20. 0/2 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 11, 2025
  21. 1/2 fetch: extract out reference committing logicKarthik Nayak, Nov 11, 2025
  22. 2/2 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 11, 2025
  23. Patrick SteinhardtNov 12, 2025
  24. Karthik NayakNov 12, 2025
  25. Junio C HamanoNov 12, 2025
  26. 0/2 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 13, 2025
  27. 1/2 fetch: extract out reference committing logicKarthik Nayak, Nov 13, 2025
  28. 2/2 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 13, 2025
  29. Junio C HamanoNov 13, 2025
  30. Karthik NayakNov 15, 2025
  31. Junio C HamanoNov 17, 2025
  32. Karthik NayakNov 17, 2025
  33. 0/3 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 18, 2025
  34. 1/3 fetch: extract out reference committing logicKarthik Nayak, Nov 18, 2025
  35. 2/3 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 18, 2025
  36. 3/3 fetch: fix failed batched updates skipping operationsKarthik Nayak, Nov 18, 2025
  37. Junio C HamanoNov 18, 2025
  38. Karthik NayakNov 19, 2025
  39. 0/3 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 19, 2025
  40. 1/3 fetch: extract out reference committing logicKarthik Nayak, Nov 19, 2025
  41. 2/3 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 19, 2025
  42. 3/3 fetch: fix failed batched updates skipping operationsKarthik Nayak, Nov 19, 2025
  43. Eric SunshineNov 19, 2025
  44. Junio C HamanoNov 19, 2025
  45. Karthik NayakNov 21, 2025
  46. 0/3 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 21, 2025
  47. 1/3 fetch: extract out reference committing logicKarthik Nayak, Nov 21, 2025
  48. 2/3 fetch: fix non-conflicting tags not being committedKarthik Nayak, Nov 21, 2025
  49. Patrick SteinhardtDec 1, 2025
  50. Karthik NayakDec 2, 2025
  51. 3/3 fetch: fix failed batched updates skipping operationsKarthik Nayak, Nov 21, 2025
  52. Patrick SteinhardtDec 1, 2025
  53. Karthik NayakDec 2, 2025
  54. Junio C HamanoNov 21, 2025

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.