From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH 3/7] refs: convert AUTO_MERGE to become a normal pseudo-ref
Date: Mon, 22 Jan 2024 11:45:14 +0100 [thread overview]
Message-ID: <Za5HOkWM3IQIiKDJ@tanuki> (raw)
In-Reply-To: <xmqqjzo5jf79.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]
On Fri, Jan 19, 2024 at 11:28:10AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > In 70c70de616 (refs: complete list of special refs, 2023-12-14) we have
> > inrtoduced a new `is_special_ref()` function that classifies some refs
>
> "introduced"
>
> > @@ -4687,10 +4685,17 @@ void merge_switch_to_result(struct merge_options *opt,
> > trace2_region_leave("merge", "record_conflicted", opt->repo);
> >
> > trace2_region_enter("merge", "write_auto_merge", opt->repo);
> > - filename = git_path_auto_merge(opt->repo);
> > - fp = xfopen(filename, "w");
> > - fprintf(fp, "%s\n", oid_to_hex(&result->tree->object.oid));
> > - fclose(fp);
> > + if (refs_update_ref(get_main_ref_store(opt->repo), "", "AUTO_MERGE",
> > + &result->tree->object.oid, NULL, REF_NO_DEREF,
> > + UPDATE_REFS_MSG_ON_ERR)) {
> > + /* failure to function */
> > + opt->priv = NULL;
> > + result->clean = -1;
> > + merge_finalize(opt, result);
> > + trace2_region_leave("merge", "write_auto_merge",
> > + opt->repo);
> > + return;
> > + }
> > trace2_region_leave("merge", "write_auto_merge", opt->repo);
> > }
> > if (display_update_msgs)
>
> We used to ignore errors while updating AUTO_MERGE, implying that it
> is an optional nicety that does not have to block the merge. Now we
> explicitly mark the resulting index unclean. While my gut feeling
> says that it should not matter all that much (as such a failure
> would be rare enough that the user may want to inspect and double
> check the situation before going forward), I am not 100% sure if the
> change is behaviour is acceptable by everybody (cc'ed Elijah for
> second opinion).
We only ignored _some_ errors when updating AUTO_MERGE. Most notably we
die when we fail to create the file, but we succeed in case its contents
aren't written. This does not make much sense to me -- my expectation
would be that we should verify either the complete operation or nothing
of it and ignore all failures. Gracefully leaving an empty file behind
is a weird in-between state, so I'd claim it's more or less an oversight
that we did not perform proper error checking here.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-22 10:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 10:39 [PATCH 0/7] refs: convert special refs to become normal pseudo-refs Patrick Steinhardt
2024-01-19 10:39 ` [PATCH 1/7] sequencer: clean up pseudo refs with REF_NO_DEREF Patrick Steinhardt
2024-01-19 19:14 ` Junio C Hamano
2024-01-22 10:36 ` Patrick Steinhardt
2024-01-22 11:49 ` Karthik Nayak
2024-01-22 12:28 ` Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 2/7] sequencer: delete REBASE_HEAD in correct repo when picking commits Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 3/7] refs: convert AUTO_MERGE to become a normal pseudo-ref Patrick Steinhardt
2024-01-19 19:28 ` Junio C Hamano
2024-01-22 10:45 ` Patrick Steinhardt [this message]
2024-01-24 3:19 ` Elijah Newren
2024-01-22 12:02 ` Karthik Nayak
2024-01-19 10:40 ` [PATCH 4/7] sequencer: introduce functions to handle autostashes via refs Patrick Steinhardt
2024-01-19 20:09 ` Junio C Hamano
2024-01-22 10:51 ` Patrick Steinhardt
2024-01-22 19:54 ` Phillip Wood
2024-01-22 20:16 ` Junio C Hamano
2024-01-19 10:40 ` [PATCH 5/7] refs: convert MERGE_AUTOSTASH to become a normal pseudo-ref Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 6/7] refs: redefine special refs Patrick Steinhardt
2024-01-19 20:28 ` Junio C Hamano
2024-01-19 10:40 ` [PATCH 7/7] Documentation: add "special refs" to the glossary Patrick Steinhardt
2024-01-23 16:27 ` Phillip Wood
2024-01-24 9:05 ` Patrick Steinhardt
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=Za5HOkWM3IQIiKDJ@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
/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.