Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2017, 15:24 UTC
Message-ID: <xmqqpocloqcp.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <6a71f802-b20c-f6bc-7bb5-8d81db3353d8@talktalk.net>

Phillip Wood <phillip.wood@talktalk.net> writes:

Show 5 quoted lines

>> On 26/07/17 23:12, Junio C Hamano wrote:
>>> I think
>>> you are already 80% there without adding a yet another option,...
>> ...
>> I'm interested in the 20% as it's about 100% of my rebase conflicts.

OK, then at least a fixed --rerere-autoupdate would hopefully limit the scope of the additional 20%; I'd suspect that a new option would also internally turn on --rerere-autoupdate, so that the remaining changes you would see upon --continue would be limited to what the user had to manually resolve (and edit without having textual conflict, aka evil merge to resolve semantic conflicts).

I am *not* opposed to an option to tell the command to blindly take such remaining changes, as long as it stays optional---the use of the option can then be taken as a strong signal that the user is OK with the local changes in the working tree, even if the user may not have marked them as resolved with "git add".

Show 8 quoted lines

>>> And from the
>>> workflow point of view, encouraging them to "git add" their manual
>>> resolution after they are satisified with their changes by not doing
>>> "git add" blindly for all changes, like your --autostage" does, is
>>> probably a good thing.
>
> Git allows 'git commit -a' to complete a conflicted merge which I
> think is much the same thing as I'm proposing....

"-a" is a strong enough sign that the user is OK with all the paths; "git commit" without an option does not. So it is OK for a new option (perhaps "--all-autoupdate", which does more than the existing "--rerere-autoupdate") to become the signal that the user is OK with all the local changes.

This is a tangent, but concluding a merge with "commit -a" (or "add -u && commit -a") has always been discouraged among Git expert users, and it will stay to be so. If you search the list archive, you would find a good explanation by Linus on this, but a short version is that this is because it is normal to start a merge in a dirty working tree where the user has local changes that the user knows will not interfere with the merge.

Because "rebase" refuses to work in a dirty working tree, the analogy with "merge" does not quite hold. Doing "add -u" before telling it to "--continue" would be much safer.

Thanks.