From: phillip.wood123@gmail.com
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Cc: Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction
Date: Thu, 3 Apr 2025 16:08:22 +0100 [thread overview]
Message-ID: <08837a1a-b46d-4456-beba-5c889fe9e674@gmail.com> (raw)
In-Reply-To: <15222e69-9452-fd61-6ffc-8c8de0c68d8a@gmx.de>
Hi Johannes
On 03/04/2025 13:17, Johannes Schindelin wrote:
> Hi Phillip,
> On Wed, 2 Apr 2025, phillip.wood123@gmail.com wrote:
>> On 01/04/2025 17:22, Johannes Schindelin wrote:
>>
>>> It is unfortunate that we cannot fix this, as `git commit` with an
>>> interrupted `pick` _would_ retain authorship, right?
>>
>> Unfortunately not. Running "git commit" rather than "git rebase
>> --continue" to commit a conflict resolution when rebasing always loses
>> the authorship.
>>
>>> (Why is that so? Can we really not use the same trick with `merge`s?)
>
> Authorship is retained when a `git cherry-pick` (what an unwieldy command
> name for _such_ a common operation!) failed with merge conflicts and those
> conflicts were resolved and the user then calls `git commit`, though.
>
> Why can this technique not be used in interrupted `pick`/`merge` commands
> of `git rebase`?`git cherry-pick` retains authorship by writing CHERRY_PICK_HEAD which
`git commit` uses to look up the commit message and authorship. When
we're rebasing the sequencer removes CHERRY_PICK_HEAD and instead writes
the commit message to MERGE_MSG and the authorship to
.git/rebase-merge/author-script. I think the reason for the different
behavior is to avoid confusing things like `git status`.
CHERRY_PICK_HEAD has been removed when rebasing since it was introduced
in d7e5c0cbfb0 (Introduce CHERRY_PICK_HEAD, 2011-02-19). These days
rebase supports --reset-author-date which means it cannot use the same
mechanism as cherry-pick. Personally I'd much rather we tell people to
use "git rebase --continue" to commit their conflict resolutions as
using "git commit" has never worked if one wanted to preserve authorship
and I think making it work would be a pain and probably fragile as I'm
not sure how we'd ensure "git commit" knew it was committing a conflict
resolution created by "git rebase" rather than one created by some other
commit run while the rebase was stopped or by an exec command.
Best Wishes
Phillip
next prev parent reply other threads:[~2025-04-03 15:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 17:03 [PATCH 0/3] rebase -r: a bugfix and two status-related improvements Philippe Blain via GitGitGadget
2025-03-28 17:03 ` [PATCH 1/3] rebase -r: do create merge commit after empty resolution Philippe Blain via GitGitGadget
2025-03-28 17:14 ` Eric Sunshine
2025-03-28 17:23 ` Eric Sunshine
2025-04-01 16:17 ` Johannes Schindelin
2025-03-31 15:37 ` Phillip Wood
2025-03-28 17:03 ` [PATCH 2/3] wt-status: also abbreviate 'merge' and 'fixup -C' lines during rebase Philippe Blain via GitGitGadget
2025-03-31 15:37 ` Phillip Wood
2025-03-28 17:03 ` [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction Philippe Blain via GitGitGadget
2025-03-31 15:38 ` Phillip Wood
2025-04-01 16:22 ` Johannes Schindelin
2025-04-02 13:09 ` phillip.wood123
2025-04-03 12:17 ` Johannes Schindelin
2025-04-03 15:08 ` phillip.wood123 [this message]
2025-04-04 11:41 ` Johannes Schindelin
2025-04-04 14:13 ` Phillip Wood
2025-03-31 15:38 ` [PATCH 0/3] rebase -r: a bugfix and two status-related improvements Phillip Wood
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=08837a1a-b46d-4456-beba-5c889fe9e674@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=levraiphilippeblain@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 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).