Matthieu Moy wrote: > No, you don't. Just try if you're not convinced: Oh, I trusted the documentation on this one and never tried with a dirty worktree myself. Please fix the documentation, if you know how exactly to correct it.
> No, I'm not proposing to do anything for merge. There's no reason to try > being uniform in conflict resolution for pull-merge and pull-rebase as > it is already different now. We already have "git rebase --continue", we > don't have "git merge --continue". So what? The fact that merge doesn't > have the equivalent doesn't mean we should not do something for "rebase > --continue". Well, you can't blame me for the misunderstanding then. In a previous email, you wrote: > 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. Junio's criticism of pull.autostash hurting pull-merge people is cogent; my current plan is to ditch pull.autostash altogether, and implement rebase.autostash for the reduced case of a non-interactive rebase. -- 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
