git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).