Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > I wonder if it makes sense to automate that even more and make git > pull behave a bit statefully like rebase does: Making things stateful may help, but when done without thinking the consequence through, it would make things more confusing. By the way, I never liked the way 'git rebase --continue' works. Don't get me wrong. I think it *was* a vast improvement. Before 'git rebase --continue' was introduced, you needed to know the implementation detail of 'git rebase' well enough to know that you have to say 'git am --resolved' after resolving the conflicts. Compared to that, being able to tell rebase to "continue" is much nicer. But in practice, after 'git rebase' stops on a conflicting merge, I spend many braincycles to come up with a sensible merge and then many CPU cycles to run test, and by the time I do the final "git diff" to make sure everything look right and "update-index" them, I often end up getting confused and find me asking this question: what was I doing? Was I resolving the merge because I merged, or was I in the middle of a rebase, or was I applying from a mailbox? I do not know what would happen if I say "git commit" at that point, but I suspect it would be unpleasant, so I have never tried it myself. But it takes nontrivial amount of effort to convince myself that 'git rebase --continue' is what I want to do next, not 'git commit' nor 'git am --resolved'. And I suspect the reason this is confusing to me is not that rebase keeps state but that the state is not made more obvious to prevent mistakes from happening. Earlier I mentioned perhaps we would want "git, whatnow?" command to remind people what they were in the middle of and suggest what the next step would be. Or perhaps "git, continue" command that makes the obvious next step to happen would be helpful. I am very much afraid that introducing more hidden state without such "what now?" framework in place would make things more confusing and harder to use, not easier. > When git pull --continue does the commit, it *might* be nice for it to > do a variant of commit -a: if the user has modified all the > conflicting files, *and* not done an update-index on any of them > manually, then do the update-index implicitly. (That "and" part would > be to prevent it from tripping up experienced git users who want to > manually mark the conflicting files as resolved by running > update-index.) I'm not sure that's actually a good idea, though it'd > save some commands most of the time; the danger, of course, is that > you could end up committing a half-resolved file by accident. But then > I guess there's nothing preventing you from doing that with > update-index today. Running update-index by hand is a conscious act on the part of the user. You cannot compare it with silently doing the equivanent without telling the user and screwing up. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html