On 27/07/17 16:24, Junio C Hamano wrote: > Phillip Wood <phillip.wood@xxxxxxxxxxxx> 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 can see the logic in that but I was imagining (and the patches implement) that the --autostage option would be passed to 'rebase --continue' not when the rebase was started by which time it is too late to turn on --rerere-autoupdate for the current conflicts. I prefer having to pass --autostage with --continue so that it is a concious decision by the user to stage unstaged changes when they continue rather than rebase just doing it each time it continues. > 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". I agree it definitely needs to be optional (possibly with a config option to have it on by default but I'm not wedded to that as it is easy to set up a git or shell alias) What is the best way forward on this? The patches I posted add a '--autostage' option to be passed with '--continue' which means that staging all the unstaged changes remains optional but does not allow --rerere-autoupdate to be automatically enabled. I'm not sure about the check for merge markers, as it is implemented it also checks for whitespace errors which is really the domain of the pre-commit hook. If we go for an explicit --autostage without the config key to make it on by default then maybe it is OK to drop the check, but it keeping it could be a useful safety measure. I don't think it would be too much work the change diff to allow '--check=merge-markers' as internally the whitespace and marker checks are implemented separately. Best Wishes Phillip >>>> 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. > > >
