Steven Grimm [off-list ref] 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.
Junio C Hamano [off-list ref] wrote:
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 use bash, right? What about teaching your PS1 how to show
you if you are in the middle of a rebase? Doesn't it show you
the current branch already? ;-)
--
Shawn.
On 2007-04-19 16:30:12 -0700, Junio C Hamano wrote:
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?
This is the main selling point of StGIT, in my opinion. It keeps track
of stuff for you when you rebase, so you won't accidentally forget
things. The extra help isn't needed much when everything goes
smoothly, but as soon as you get a conflict or three in the middle of
rebasing a largish stack, it's invaluable to just be able to say "stg
series" to see which patches have been applied to HEAD, and which are
still floating in limbo.
The usability increase is very palpable; without it, I wouldn't even
attempt many of the rebasings I do, even though they are technically
perfectly possible to do with just git.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
Junio C Hamano [off-list ref] wrote:
Steven Grimm [off-list ref] writes:
quoted
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