Junio C Hamano <junkio@xxxxxxx> wrote: > 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. [...] > 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. You have even implemented "git explain" command, but it didn't get into git. Perhaps it is time to resurrect it. > 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. It would be nice to have such "git explain" command, both for use in scripts (and perhaps also in builtins), and for the user (perhaps "git status" should use it, too). And it could be used to implement "git continue" and "git abort" commands... (or "git, continue" and "git, abort" ;-). -- Jakub Narebski Poland - 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