Ramkumar Ramachandra <artag...@gmail.com> writes:
> In the pull-merge case, maybe: if your worktree isn't clean, you lose
> a lot of goodies like merge --abort anyway, and I hate that.
AFAICT, "git merge --abort" is an alias for "git reset --merge" which
was precisely designed to reset only modifications comming from a merge,
and not the local changes that were present before the merge was
started. The man pages are relatively obscure on the subject, but I'd
call that a documentation bug.
> Overall, I don't see how an extra stash/ stash pop where not
> absolutely necessary hurts.
It does. stashing means the user will have to "stash pop" later. One
extra step, one extra opportunity to forget something important.
A minor annoyance is that it will touch files that have no reason to be
touched, hence may trigger extra rebuilds with "make", disturbing text
editors that have the file open, etc.
The fact that "git pull" just works on dirty trees with non-overlapping
changes is an important feature of Git.
>> Shouldn't this belong to "git merge" instead (i.e. implement "git merge
>> --autosquash" and call it from "git pull")? Users doing "git fetch &&
>> git merge" by hand should be able to use --autosquash, I think.
> --autosquash reminds me of rebase.autosquash, and that is completely
> unrelated to the issue at hand.
A typo seems to have propagated in this thread. I meant auto*stash*, not
auto*squash*, sorry. I guess it's the same typo in Junio's message.
>> Something should be done for "git rebase" and "git pull --rebase" too.
>> In this case, the UI can be much smoother, since the user would have to
>> run "git rebase --continue" anyway, so you can do the auto-stash-pop for
>> him by adding something like "exec git stash pop" at the end of the
> No. I'm against executing a special codepath for a pull-rebase that
> has no equivalent in the pull-merge world.
I think you're taking it the wrong way. You seem to insist that
autostash should be a pull feature. I think it should be a feature of
merge and rebase, and the convenience script "git pull" should expose
them to the user.
I see no reason to prevent users running fetch and then merge or rebase
to use the autostash feature.
>> Ideally, "git rebase --abort" should auto-stash-pop too, although this
>> is much less trivial to implement.
> As I already pointed out in my message to Junio, "fixing" rebase is
> not the topic of discussion at all.
It's not about fixing the existing rebase. It's about implementing
autostash the right way.
As a user, when I run "git rebase --continue" and it tells me it's done,
I expect the work to actually be done. This is the case today. This
won't be the case after autostash is introduced if the user has to
remember to run "stash pop" afterwards.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html