RE: Regression in 'git pull --rebase --autostash' since v2.32.0

[Felipe Contreras <felipe.contreras@gmail.com>]

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