Hello,
Philippe Blain wrote:
> Your recent clean-up of 'git pull --autostash' seems to unfortunately have made things
> worse if the pull brings new files that conflict with existing untracked files,
> which makes the pull abort,
> and there are tracked files with modifications (so --autostash comes into play).
>
> Before your change, 'git pull --no-rebase --autostash' did *not* apply the autostash
> after the pull failed, thus loosing modifications to tracked files (and it did not save the
> stash entry !). 'git pull --rebase --autostash' correctly applied the autostash, but ended with
> a strange "error: could not detach HEAD".
>
> After your change, both 'git pull --no-rebase --autostash' and 'git pull --rebase --autostash'
> have the same buggy behaviour: they do not apply the autostash and do not save it in the stash list.
>
> I had already documented the old behaviour at [1]. Here, I copy my reproducer script
> (save it as "script"):
I cannot reproduce this. In my case the reproducer script never puts
anything in the stash list.
Moreover, this is not an issue of `git pull`, but `git merge`.
I can reproduce the problem that the modifications are lost like this:
git init test
(
cd test
date >> file
git add file
git commit -m 'add file'
date >> other
git add other
git commit -m 'add other'
git checkout -b topic @~
date >> other
date >> file
git status
git "$@" master
git status
git stash list
)
Running this with 'rebase --autostash' fails and nothing is put in the
stash list, but the modifications to 'file' remain. I think this is the
correct behavior.
But with 'merge --autostash' the modifications to 'file' are lost. That
is a bug, and it's already present in v2.32.
Do you agree?
--
Felipe Contreras
