From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Phillip Wood <phillip.wood@dunelm.org.uk>,
Elijah Newren <newren@gmail.com>,
Phillip Wood <phillip.wood123@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 0/2] checkout -m: recreate conflict labels
Date: Wed, 30 Sep 2026 13:40:34 -0700 [thread overview]
Message-ID: <xmqqmrsy8ocd.fsf@gitster.g> (raw)
In-Reply-To: <223c99ea-64d9-46da-9631-ed8035f1a062@kdbg.org> (Johannes Sixt's message of "Wed, 30 Sep 2026 22:24:33 +0200")
Johannes Sixt <j6t@kdbg.org> writes:
> Am 30.09.26 um 11:48 schrieb Phillip Wood:
>> When "git checkout -m <path>" recreates a merge conflict, it uses
>> the labels "base", "ours", "theirs", rather than the labels used by
>> the original merge. This short series teaches the ort machinery to
>> write the labels to ".git/MERGE_LABELS" when it switches to a merge
>> result containing conflicts, so that "git checkout -m" can then read
>> that file and use the same labels.
>
> Would an index extension not be a better place to store auxiliary
> information about merges?
Wow. MERGE_HEAD, CHERRY_PICK_HEAD, and all others replaced with
index extensions? That would unclutter $GIT_DIR/ quite a lot (for
some reason, I find ORIG_HEAD is a bit of eyesore). It makes the
information less accessible, so I am not sure how I feel about the
proposal, but it is an interesting thought.
Thanks.
next prev parent reply other threads:[~2026-09-30 20:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 9:48 [PATCH 0/2] checkout -m: recreate conflict labels Phillip Wood
2026-09-30 9:48 ` [PATCH 1/2] remove_branch_state: convert boolean argument to flags Phillip Wood
2026-09-30 9:48 ` [PATCH 2/2] merge: remember conflict labels Phillip Wood
2026-09-30 16:42 ` Junio C Hamano
2026-10-01 8:54 ` Phillip Wood
2026-10-01 17:14 ` Junio C Hamano
2026-09-30 20:24 ` [PATCH 0/2] checkout -m: recreate " Johannes Sixt
2026-09-30 20:40 ` Junio C Hamano [this message]
2026-09-30 21:20 ` Johannes Sixt
2026-10-01 8:45 ` Phillip Wood
2026-10-05 13:24 ` [PATCH v2 " Phillip Wood
2026-10-05 13:24 ` [PATCH v2 1/2] remove_branch_state: convert boolean argument to flags Phillip Wood
2026-10-05 13:24 ` [PATCH v2 2/2] merge: remember conflict labels Phillip Wood
2026-10-05 16:19 ` Junio C Hamano
2026-10-06 15:21 ` Phillip Wood
2026-10-05 16:31 ` Junio C Hamano
2026-10-06 15:05 ` Phillip Wood
2026-10-06 15:46 ` Junio C Hamano
2026-10-07 13:38 ` Phillip Wood
2026-10-05 14:48 ` [PATCH v2 0/2] checkout -m: recreate " Johannes Sixt
2026-10-05 15:09 ` Phillip Wood
2026-10-05 15:53 ` Junio C Hamano
2026-10-09 9:13 ` [PATCH v3 " Phillip Wood
2026-10-09 9:13 ` [PATCH v3 1/2] remove_branch_state: convert boolean argument to flags Phillip Wood
2026-10-09 9:13 ` [PATCH v3 2/2] merge: remember conflict labels Phillip Wood
2026-10-10 0:24 ` Junio C Hamano
2026-10-12 14:10 ` Phillip Wood
2026-10-12 15:09 ` Junio C Hamano
2026-10-09 20:31 ` [PATCH v3 0/2] checkout -m: recreate " Junio C Hamano
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=xmqqmrsy8ocd.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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.