Ramkumar Ramachandra [off-list ref] writes:
+stash_required () {
+ ! (git diff-files --quiet --ignore-submodules &&
+ git diff-index --quiet --cached HEAD --ignore-submodules)
+}
Isn't this too pessimistic? If the local changes do not overlap (in
terms of files) with the pulled changes, then autosquash is not needed.
There should be a test for the case of non-overlapping changes.
+if test "$autostash" = true && stash_required
+then
+ git stash || die "$(gettext "Cannot autostash")" &&
+ require_clean_work_tree "pull" "Please commit or stash them." &&
+ if eval "$eval"
+ then
+ git stash pop || die "$(gettext "Cannot pop stash")"
+ else
+ exit_code=$?
+ echo "Please run 'git stash pop' after commiting the conflict resolution."
+ exit $exit_code
+ fi
+else
+ eval "exec $eval"
+fi
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.
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 todo-list.
Ideally, "git rebase --abort" should auto-stash-pop too, although this
is much less trivial to implement.
Maybe a good first step is to implement --autosquash only for non-rebase
pull, and later to implement "git rebase --autosquash" and call it from
"git pull".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Matthieu Moy wrote:
Isn't this too pessimistic? If the local changes do not overlap (in
terms of files) with the pulled changes, then autosquash is not needed.
There should be a test for the case of non-overlapping changes.
In the pull-rebase case, no; it is not too pessimistic.
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.
Secondly, it's impossible to determine whether the changes overlap or
not before actually running merge_trees(). If there were an easy way
to do it, I might have considered it.
Overall, I don't see how an extra stash/ stash pop where not
absolutely necessary hurts.
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. Did you mean git merge --squash (to
update the worktree/index but not create the actual commit?). Sure,
it's probably useful to have a merge.squash configuration variable,
but I don't see what it has to do with the pull.autostash I'm
proposing.
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 todo-list.
No. I'm against executing a special codepath for a pull-rebase that
has no equivalent in the pull-merge world. Or did you mean: have one
configuration variable to git merge --squash and do this for git
rebase, as if they're equivalent from the pull perspective? No, they
aren't.
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.
Maybe a good first step is to implement --autosquash only for non-rebase
pull, and later to implement "git rebase --autosquash" and call it from
"git pull".
"Implement" git rebase --autosquash? If I just set rebase.autosquash
to true, the rebase will automatically autosquash whether called from
git pull or otherwise. Sorry, I just don't understand what you're
saying.