Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

From: Phillip Wood <phillip.wood@talktalk.net>
Date: Apr 25, 2018, 17:09 UTC
Message-ID: <949b5749-d721-31ea-77a1-ec6406f3083a@talktalk.net>
In-Reply-To: <nycvar.QRO.7.76.6.1804251442510.4978@tvgsbejvaqbjf.bet>

On 25/04/18 13:48, Johannes Schindelin wrote:

Show 35 quoted lines

> Hi Phillip,
> 
> On Mon, 23 Apr 2018, Phillip Wood wrote:
> 
>> On 23/04/18 19:11, Stefan Beller wrote:
>>>
>>> On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin
>>> <johannes.schindelin@gmx.de> wrote:
>>>> Eric Sunshine pointed out that I had such a commit message in
>>>> https://public-inbox.org/git/CAPig+cRrS0_nYJJY=O6cboV630sNQHPV5QGrQdD8MW-sYzNFGQ@mail.gmail.com/
>>>> and I went on a hunt to figure out how the heck this happened.
>>>>
>>>> Turns out that if there is a fixup/squash chain where the *last* command
>>>> fails with merge conflicts, and we either --skip ahead or resolve the
>>>> conflict to a clean tree and then --continue, our code does not do a
>>>> final cleanup.
>>>>
>>>> Contrary to my initial gut feeling, this bug was not introduced by my
>>>> rewrite in C of the core parts of rebase -i, but it looks to me as if
>>>> that bug was with us for a very long time (at least the --skip part).
>>>>
>>>> The developer (read: user of rebase -i) in me says that we would want to
>>>> fast-track this, but the author of rebase -i in me says that we should
>>>> be cautious and cook this in `next` for a while.
>>>
>>> I looked through the patches again and think this series is good to go.
>>
>> I've just realized I commented on an outdated version as the new version was
>> posted there rather than as a reply to v1. I've just looked through it and I'm
>> not sure it addresses the unnecessary editing of the commit message of the
>> previous commit if a single squash command is skipped as outlined in
>> https://public-inbox.org/git/b6512eae-e214-9699-4d69-77117a0daec3@talktalk.net/
> 
> I have not forgotten about this! I simply did not find the time yet, is
> all...

I wondered if that was the case but I wanted to check as I wasn't sure if you'd seen the original message as it was on an obsolete version of the series

Show 6 quoted lines

> The patch series still has not been merged to `next`, but I plan on
> working on your suggested changes as an add-on commit anyway. I am not
> quite sure yet how I want to handle the "avoid running commit for the
> first fixup/squash in the series" problem, but I think we will have to add
> *yet another* file that is written (in the "we already have comments in
> the commit message" conditional block in error_failed_squash())...

I wonder if creating the file in update_squash_messages() rather than error_failed_squash() would be a better approach as then it is easy to only create rebase_path_amend_type() when there has already been a squash or fixup. The file is removed in the loop that picks commits in pick_commits() so it would be cleaned up at the beginning of the next pick if it's not needed.

Best Wishes

Phillip

> 
> Ciao,
> Dscho
>