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

[Phillip Wood <phillip.wood@talktalk.net>]

On 26/04/18 10:51, Johannes Schindelin wrote:
> Hi Phillip,
> 
> On Wed, 25 Apr 2018, Phillip Wood wrote:
> 
>> On 25/04/18 13:48, Johannes Schindelin wrote:
>>>
>>> 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
>>
>>> 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.
> 
> That would be a good idea in general, but I think we have to take care of
> the following scenario:
> 
> 	pick	<- succeeds
> 	squash	<- succeeds
> 	fixup	<- fails, will be skipped
> 
> In this case, we do need to open the editor. But in this scenario, we do
> not:
> 
> 	pick	<- succeeds
> 	fixup	<- succeeds
> 	squash	<- fails, will be skipped
> 
> If we write the amend-type file in update_squash_messages(), we would
> write "squash" into it in both cases. My hope was to somehow avoid that.

Good point, I'd not thought of that

> I just realized that the current iteration does not fulfill that goal, as
> the message-fixup file would be long gone by the time
> error_failed_squash() was called in the latter example.
> 
> Also, I realized something else: my previous work-around for the
> GETTEXT_POISON case (where I fail gently when a commit message does not
> contain the "This is a combination of #<count> commits" count in ASCII)
> would be much superior if it simply would not abuse the comment in the
> commit message, but had a robust, non-l18ned way to count the fixup/squash
> commits.
> 
> My current thinking is to reconcile both problems by shunning the
> amend-type and instead just record the sequence of fixup/squash commits
> that went into HEAD, in a new file, say, current-fixups.
> 
> To answer the question how many commit messages are combined, I then
> simply need to count the lines in that file.
> 
> To answer the question whether a skipped fixup/squash requires the editor
> to be launched, I can simply look whether there is a "squash" line
> (ignoring the last line).

That sounds like a good plan, keeping count of the fixup/squash without
having to parse the last message is a good idea.

> Oh, and I also forgot to test whether this is the "final fixup". If we are
> skipping a "fixup" in the middle of a chain, there is no need to clean the
> commit message to begin with.
> 
> This will take a while... ;-)

Yes, it sounds like quite a bit of work, but it will be a very
worthwhile improvement.

Thanks

Phillip

> Ciao,
> Dscho
>