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


  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).