From: Felipe Contreras <felipe.contreras@gmail.com>
To: Philippe Blain <levraiphilippeblain@gmail.com>,
Felipe Contreras <felipe.contreras@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>,
Denton Liu <liu.denton@gmail.com>
Subject: RE: Regression in 'git pull --rebase --autostash' since v2.32.0
Date: Sat, 17 Jul 2021 14:34:24 -0500 [thread overview]
Message-ID: <60f330c09ee05_25f220867@natae.notmuch> (raw)
In-Reply-To: <a0071549-73f6-9636-9279-3f01143a05de@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
next prev parent reply other threads:[~2021-07-17 19:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-17 15:29 Regression in 'git pull --rebase --autostash' since v2.32.0 Philippe Blain
2021-07-17 17:03 ` Philippe Blain
2021-07-17 19:34 ` Felipe Contreras [this message]
2021-07-17 23:02 ` Philippe Blain
2021-07-18 3:05 ` Felipe Contreras
2021-07-23 12:17 ` Philippe Blain
2021-07-23 16:11 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60f330c09ee05_25f220867@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=levraiphilippeblain@gmail.com \
--cc=liu.denton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).