Re: GIT vs Other: Need argument

[Junio C Hamano <junkio@cox.net>]

Steven Grimm <koreth@midwinter.com> 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.