From: phillip.wood123@gmail.com
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood@dunelm.org.uk>,
Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction
Date: Wed, 2 Apr 2025 14:09:22 +0100 [thread overview]
Message-ID: <a81dbb21-b50b-4358-b2d4-7f804b66bcbc@gmail.com> (raw)
In-Reply-To: <0bd7e0c1-fe73-9e16-0737-d6b175a60dd3@gmx.de>
Hi Johannes
On 01/04/2025 17:22, Johannes Schindelin wrote:
> Hi Philippe,
>
> On Fri, 28 Mar 2025, Philippe Blain via GitGitGadget wrote:
>
>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>>
>> Since 982288e9bd (status: rebase and merge can be in progress at the
>> same time, 2018-11-12), when a merge is in progress as part of a 'git
>> rebase -r' operation, 'wt_longstatus_print_state' shows information
>> about the in-progress rebase (via show_rebase_information), and then
>> calls 'show_merge_in_progress' to help the user conclude the merge. This
>> function suggests using 'git commit' to do so, but this throws away the
>> authorship information from the original merge, which is not ideal.
>
> 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.
Best Wishes
Phillip
(Why is that so? Can
> we really not use the same trick with `merge`s?)
>
> Ciao,
> Johannes
next prev parent reply other threads:[~2025-04-02 13:09 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 [this message]
2025-04-03 12:17 ` Johannes Schindelin
2025-04-03 15:08 ` phillip.wood123
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=a81dbb21-b50b-4358-b2d4-7f804b66bcbc@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).