Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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.
Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
and pull.autosquash is harmful.
But for pull-rebase folks, I can understand why this "working tree
must be squeakily clean" logic is appropriate, if we were to do
this. The root cause is because rebase insists to be run on such a
working tree.
And the worst part is that in order to check if local changes
overlap, you need to fetch first. But Ram's annoyance is about the
user being told the merge/rebase cannot proceed _after_ fetch is
done.
> 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.
See my other message. I do not think autosquash would help "merge"
folks very much, and will actively hurt when it matters.
> Something should be done for "git rebase" and "git pull --rebase" too.
That I would agree. I am not sure autosquash is the best approach,
but we should be able to help them more.
--
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