Re: [PATCH v5 2/2] fetch: fix non-conflicting tags not being committed
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 17, 2025, 00:02 UTC
- Message-ID
- <xmqqtsytbk5w.fsf@gitster.g>
- In-Reply-To
- <CAOLa=ZT9wv8B7EKXJQvwR07bUT7Jx0nJSwGGyUZ8+GN3-xdRag@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
Show 15 quoted lines
>> perform. Namely, we do not >> >> - call commit_fetch_head() >> >> - run set_upstream processing >> >> - honor do_set_head flag that was left for remote that does not >> have followremotehead=never >> >> but don't we want to do some of them at least? >> > > Thanks for bringing this up. I would think we should do all of these, > but not if the '--atomic' flag is used. If the '--atomic' flag is used, > we shouldn't do anything else and simply skip to the end.
True.
So when not "--atomic", the code with these two patches will still misbehave, but it is not a regression these two patches causes. Failing to do any of the above three when "--atomic" is not in effect is a part of original regression in the previous cycle caused by the "batched ref updates". These two patches are trying to address the regression, but these three points are not covered. Am I reading the situation correctly?
> That said, we could either append this change as a new commit with some > additional tests and re-roll the series or send it as a separate commit > based on this series. I'd prefer the latter so that we have the fix for > fetching tags merged sooner, but happy to do either.
Either is fine, as this won't make Git 2.52, it seems. It is OK as it is not a new regression, but it still is a recent one, and would be nice if we have something concrete to address it soon after 2.52.
Thanks.