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

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

Hmph, but what 'a' in "commit -a" wants to convey is "all", and in the context of "rebase" we want to avoid saying "all". A user can be confused into thinking "all" refers to "all subsequent commits" not "all paths conflicted".

Besides, with the $something_here option, the user is explicitly telling us that the user finisished the resolution of conflicts left in the working tree. There is nothing "auto" about it.

The more I think about this, the more I am convinced that it is a very bad idea to give such a $something_here option only to "rebase".

The standard flow for any operation that could stop in the middle because the command needs help from the user with conflicts that cannot be mechanically resolved is

 (1) write out conflicted state in the working tree, and mark these
     paths in the index by leaving them in higher stages
     (i.e. "ls-files -u" would list them);

 (2) the user edits them and marks the ones that are now resolved;

 (3) the user tells us to "continue".

and this is not limited to "rebase". "cherry-pick", "am", and "revert" all share the above, and even "merge" (which is a single commit operation to which "continue" in its original meaning---to tell us the user is done with this step and wants us to go on processing further commits or patches---does not quite apply) does.

And "rebase" is an oddball in that it is the only command that we could deduce which files in the working tree should be "add"ed, i.e. "all the files that are different from HEAD". All others allow users to begin in a dirty working tree (they only require the index to be clean), so your

	git [cherry-pick|am|revert] --continue $something_here

cannot be "git add -u && git [that command] --continue". Blindly taking any and all files that have modifications from HEAD will produce a wrong result.

You cannot even sanely solve that by first recording the paths that are conflicted before giving control back to the user and limit the "add" to them, i.e. doing "git add" only for paths that appear in "git ls-files -u" output would not catch additional changes the was needed in files that did not initially conflict (i.e. "evil merge" will have to modify a file that was not involved in the mechanical part of the conflict), because out of the files that are dirty in the working tree, some are evil merge resolutions and others are ones that were dirty from the beginning.

The only reason "git rebase" can get away without having to worry about all of the above is because it insists that the working tree is clean before it begins. In the ideal world, however, we would want to lift that and allow it to start in a working tree that has an unfinished local modification that does not interfere with the rebase, just like all other operations that could stop upon a conflict. And when that happens, your $something_here option to "git rebase --continue" will have to worry about it, too.

So...