Phillip Wood <phillip.w...@talktalk.net> writes: >> 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". >>> 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.
