{"thread":{"id":"56120","subject":"Regression in 'git pull --rebase --autostash' since v2.32.0","startedAt":"2021-07-17T15:29:53Z","lastAt":"2021-07-23T16:11:36Z","messageCount":7,"participants":["Philippe Blain","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"430419","messageId":"a0071549-73f6-9636-9279-3f01143a05de@gmail.com","threadId":"56120","inReplyTo":null,"subject":"Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-07-17T15:29:47Z","receivedAt":"2021-07-17T15:29:53Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Felipe,\n\nYour recent clean-up of 'git pull --autostash' seems to unfortunately have made things\nworse if the pull brings new files that conflict with existing untracked files,\nwhich makes the pull abort,\nand there are tracked files with modifications (so --autostash comes into play).\n\nBefore your change, 'git pull --no-rebase --autostash' did *not* apply the autostash\nafter the pull failed, thus loosing modifications to tracked files (and it did not save the\nstash entry !). 'git pull --rebase --autostash' correctly applied the autostash, but ended with\na strange \"error: could not detach HEAD\".\n\nAfter your change, both 'git pull --no-rebase --autostash' and 'git pull --rebase --autostash'\nhave the same buggy behaviour: they do not apply the autostash and do not save it in the stash list.\n\nI had already documented the old behaviour at [1]. Here, I copy my reproducer script\n(save it as \"script\"):\n\n~~~bash\n#!/bin/sh\n\n# usage: ./script <'git pull' arguments>\n\nset -x\n\nrm -rf test\nrm -rf clone\n\n# Create origin repo\ngit init test\n(\ncd test\ndate>>file\ngit add file\ngit commit -m \"add file\"\n)\n# Clone\ngit clone test clone\n# Create new file in origin\n(\ncd test\ndate>>other\ngit add other\ngit commit -m \"add other\"\n)\n# Create the same file in clone (untracked)\n(\ncd clone\ndate>>other\n# If testing '--autostash', add some modifications to 'file'\nif [[ \"$@\" =~ \"--autostash\" ]]; then\n   date>>file\nfi\n# status before pull\ngit status\n# Try to pull\ngit pull \"$@\"\n# status after pull\ngit status\n# see if the stash was saved\ngit stash list\n)\n~~~\n\n\nHere are the buggy results :\n\n** ./script --no-rebase --autostash **\n\n~~~\n+ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nChanges not staged for commit:\n   (use \"git add <file>...\" to update what will be committed)\n   (use \"git restore <file>...\" to discard changes in working directory)\n\tmodified:   file\n\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n\tother\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n+ git pull --no-rebase --autostash\nremote: Enumerating objects: 4, done.\nremote: Counting objects: 100% (4/4), done.\nremote: Compressing objects: 100% (2/2), done.\nremote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0\nUnpacking objects: 100% (3/3), 283 bytes | 94.00 KiB/s, done.\n From /Users/Philippe/Code/GIT-devel/BUGS/ggg-759-pull-autotash-untracked/test\n    4ebab2f..fc7a169  master     -> origin/master\nUpdating 4ebab2f..fc7a169\nCreated autostash: cfd51b5\nerror: The following untracked working tree files would be overwritten by merge:\n\tother\nPlease move or remove them before you merge.\nAborting\n+ git status\nOn branch master\nYour branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.\n   (use \"git pull\" to update your local branch)\n\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n\tother\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n+ git stash list\n# empty!\n~~~\n\n** ./script --rebase --autostash **\n\n~~~\n+ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nChanges not staged for commit:\n   (use \"git add <file>...\" to update what will be committed)\n   (use \"git restore <file>...\" to discard changes in working directory)\n\tmodified:   file\n\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n\tother\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n+ git pull --rebase --autostash\nremote: Enumerating objects: 3, done.\nremote: Counting objects: 100% (3/3), done.\nremote: Compressing objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0\nUnpacking objects: 100% (2/2), 223 bytes | 13.00 KiB/s, done.\n From /Users/Philippe/Code/GIT-devel/BUGS/ggg-759-pull-autotash-untracked/test\n    1aa91d4..4f8c34c  master     -> origin/master\nUpdating 1aa91d4..4f8c34c\nCreated autostash: d5dffd9\nerror: The following untracked working tree files would be overwritten by merge:\n\tother\nPlease move or remove them before you merge.\nAborting\n+ git status\nOn branch master\nYour branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.\n   (use \"git pull\" to update your local branch)\n\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n\tother\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n+ git stash list\n# empty!\n~~~\n\nReverting 221ec24e9b (Merge branch 'fc/pull-cleanups', 2021-07-08) brings\nback the old behaviour (which is still buggy for --no-rebase).\n\nI noticed (by reading the code and checking)\nthat the autostash is not completely lost, it's still pointed to by the MERGE_AUTOSTASH\nspecial ref, but this is ref is not documented (it's just mentioned without a\nclear definition).\n\nCheers,\nPhilippe.\n\n\n[1] https://github.com/gitgitgadget/git/issues/759\n"},{"id":"430431","messageId":"109545c7-7245-6146-d39a-2a44ac450db3@gmail.com","threadId":"56120","inReplyTo":"a0071549-73f6-9636-9279-3f01143a05de@gmail.com","subject":"Re: Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-07-17T17:03:44Z","receivedAt":"2021-07-17T17:03:48Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Le 2021-07-17 à 11:29, Philippe Blain a écrit :\n> Hi Felipe,\n> \n> Your recent clean-up of 'git pull --autostash' seems to unfortunately have made things\n> worse if the pull brings new files that conflict with existing untracked files,\n> which makes the pull abort,\n> and there are tracked files with modifications (so --autostash comes into play).\n> \n> Before your change, 'git pull --no-rebase --autostash' did *not* apply the autostash\n> after the pull failed, thus loosing modifications to tracked files (and it did not save the\n> stash entry !). 'git pull --rebase --autostash' correctly applied the autostash, but ended with\n> a strange \"error: could not detach HEAD\".\n> \n> After your change, both 'git pull --no-rebase --autostash' and 'git pull --rebase --autostash'\n> have the same buggy behaviour: they do not apply the autostash and do not save it in the stash list.\n\nThe change below seem to fix both cases:\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex a8a843b1f5..b2ad70c50a 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1560,6 +1560,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n  \t\t\t\t\t  &head_commit->object.oid,\n  \t\t\t\t\t  &commit->object.oid,\n  \t\t\t\t\t  overwrite_ignore)) {\n+\t\t\tapply_autostash(git_path_merge_autostash(the_repository));\n  \t\t\tret = 1;\n  \t\t\tgoto done;\n  \t\t}\n\n\n*But* from a quick audit of 'cmd_merge', there are still two code paths that\ncall 'create_autostash' but then fail to apply it before calling 'goto done':\n\n1. the branch 'if (automerge_was_ok)' (line 1693)\n2. the branch 'if (!best_strategy)' (line 1704)\n\n\nCheers,\nPhilippe.\n"},{"id":"430444","messageId":"60f330c09ee05_25f220867@natae.notmuch","threadId":"56120","inReplyTo":"a0071549-73f6-9636-9279-3f01143a05de@gmail.com","subject":"RE: Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-17T19:34:24Z","receivedAt":"2021-07-17T19:34:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hello,\n\nPhilippe Blain wrote:\n> Your recent clean-up of 'git pull --autostash' seems to unfortunately have made things\n> worse if the pull brings new files that conflict with existing untracked files,\n> which makes the pull abort,\n> and there are tracked files with modifications (so --autostash comes into play).\n> \n> Before your change, 'git pull --no-rebase --autostash' did *not* apply the autostash\n> after the pull failed, thus loosing modifications to tracked files (and it did not save the\n> stash entry !). 'git pull --rebase --autostash' correctly applied the autostash, but ended with\n> a strange \"error: could not detach HEAD\".\n> \n> After your change, both 'git pull --no-rebase --autostash' and 'git pull --rebase --autostash'\n> have the same buggy behaviour: they do not apply the autostash and do not save it in the stash list.\n> \n> I had already documented the old behaviour at [1]. Here, I copy my reproducer script\n> (save it as \"script\"):\n\nI cannot reproduce this. In my case the reproducer script never puts\nanything in the stash list.\n\nMoreover, this is not an issue of `git pull`, but `git merge`.\n\nI can reproduce the problem that the modifications are lost like this:\n\n  git init test\n  (\n    cd test\n    date >> file\n    git add file\n    git commit -m 'add file'\n    date >> other\n    git add other\n    git commit -m 'add other'\n    git checkout -b topic @~\n    date >> other\n    date >> file\n    git status\n    git \"$@\" master\n    git status\n    git stash list\n  )\n\nRunning this with 'rebase --autostash' fails and nothing is put in the\nstash list, but the modifications to 'file' remain. I think this is the\ncorrect behavior.\n\nBut with 'merge --autostash' the modifications to 'file' are lost. That\nis a bug, and it's already present in v2.32.\n\nDo you agree?\n\n-- \nFelipe Contreras\n"},{"id":"430452","messageId":"1329d238-e38a-7c8b-d468-500a0ae38bbb@gmail.com","threadId":"56120","inReplyTo":"60f330c09ee05_25f220867@natae.notmuch","subject":"Re: Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-07-17T23:02:22Z","receivedAt":"2021-07-17T23:02:35Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Felipe,\n\nLe 2021-07-17 à 15:34, Felipe Contreras a écrit :\n> Hello,\n> \n> Philippe Blain wrote:\n>> Your recent clean-up of 'git pull --autostash' seems to unfortunately have made things\n>> worse if the pull brings new files that conflict with existing untracked files,\n>> which makes the pull abort,\n>> and there are tracked files with modifications (so --autostash comes into play).\n>>\n>> Before your change, 'git pull --no-rebase --autostash' did *not* apply the autostash\n>> after the pull failed, thus loosing modifications to tracked files (and it did not save the\n>> stash entry !). 'git pull --rebase --autostash' correctly applied the autostash, but ended with\n>> a strange \"error: could not detach HEAD\".\n>>\n>> After your change, both 'git pull --no-rebase --autostash' and 'git pull --rebase --autostash'\n>> have the same buggy behaviour: they do not apply the autostash and do not save it in the stash list.\n>>\n>> I had already documented the old behaviour at [1]. Here, I copy my reproducer script\n>> (save it as \"script\"):\n> \n> I cannot reproduce this. In my case the reproducer script never puts\n> anything in the stash list.\n\nI tried again with GIT_CONFIG_GLOBAL=/dev/null on my end (and manually\nsetting GIT_AUTHOR_{NAME,EMAIL}) to be sure that my config was not playing\na role, and I still reproduce. Copying the output from my 1st email\n(for --rebase, but it's the same thing for --no-rebase):\n\n\n> ** ./script --rebase --autostash **\n> \n> ~~~\n> + git status\n> On branch master\n> Your branch is up to date with 'origin/master'.\n> \n> Changes not staged for commit:\n>   (use \"git add <file>...\" to update what will be committed)\n>   (use \"git restore <file>...\" to discard changes in working directory)\n>     modified:   file\n> \n> Untracked files:\n>   (use \"git add <file>...\" to include in what will be committed)\n>     other\n> \n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> + git pull --rebase --autostash\n> remote: Enumerating objects: 4, done.\n> remote: Counting objects: 100% (4/4), done.\n> remote: Compressing objects: 100% (2/2), done.\n> remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0\n> Unpacking objects: 100% (3/3), 283 bytes | 94.00 KiB/s, done.\n> From /Users/Philippe/Code/GIT-devel/BUGS/ggg-759-pull-autotash-untracked/test\n>    4ebab2f..fc7a169  master     -> origin/master\n> Updating 4ebab2f..fc7a169\n> Created autostash: cfd51b5\n> error: The following untracked working tree files would be overwritten by merge:\n>     other\n> Please move or remove them before you merge.\n> Aborting\n\nHere is the bug: we should see \"Applied autostash\" after \"Aborting\". The 'git status'\nbelow is to verify that the autostash was indeed not applied, and the\n'git stash list' was to check if the autostash was at least available\nin the stash list (it's not).\n\n> + git status\n> On branch master\n> Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.\n>   (use \"git pull\" to update your local branch)\n> \n> Untracked files:\n>   (use \"git add <file>...\" to include in what will be committed)\n>     other\n> \n> nothing added to commit but untracked files present (use \"git add\" to track)\n> + git stash list\n> # empty!\n> ~~~ \n\nBack to your reply:\n\n> \n> Moreover, this is not an issue of `git pull`, but `git merge`.\n> \n> I can reproduce the problem that the modifications are lost like this:\n> \n>    git init test\n>    (\n>      cd test\n>      date >> file\n>      git add file\n>      git commit -m 'add file'\n>      date >> other\n>      git add other\n>      git commit -m 'add other'\n>      git checkout -b topic @~\n>      date >> other\n>      date >> file\n>      git status\n>      git \"$@\" master\n>      git status\n>      git stash list\n>    )\n> \n> Running this with 'rebase --autostash' fails and nothing is put in the\n> stash list, but the modifications to 'file' remain. I think this is the\n> correct behavior.\n\nYes. We see the following output:\n\n     Created autostash: 69775ee\n     Applied autostash.\n     Successfully rebased and updated refs/heads/topic.\n\nThe code correctly applied the autostash after the rebase, so it's\nnormal it's not kept in the stash list. I agree it's the correct behaviour.\n\n> \n> But with 'merge --autostash' the modifications to 'file' are lost. That\n> is a bug, and it's already present in v2.32.\n\nThat's also true. From what I understand it dates back to the introduction\nof 'git merge --autostash'.\n\n> \n> Do you agree?\n> \n\nI agree that the bug with 'merge --autostash' was already present in v2.32.0.\nBut since your 340062243a (pull: cleanup autostash check, 2021-06-17),\n'git pull --rebase --autostash' calls 'git merge --autostash' in the fast-forward\ncase, and so we hit the bug, which was not the case before since the fast-forward\nmerge shortcut was skipped if '--autostash' was given for 'git pull --rebase'.\n\nThe fix I suggested in [1] seems to fix both cases, but as I wrote there\nit still leaves two code paths that might trigger the bug. I'm not familiar\nat all with the code for these two code paths, so I'm not ready to send\na formal patch; I thought I'd send the diff anyway if you or Denton (or anyone\nelse) wants to start from there.\n\nThanks,\n\nPhilippe.\n\n[1] https://lore.kernel.org/git/a0071549-73f6-9636-9279-3f01143a05de@gmail.com/T/#me6fd1cebbcbc91365bb1deff857c2fcf72db8d2d\n"},{"id":"430453","messageId":"60f39a72c9c8e_2fb208b3@natae.notmuch","threadId":"56120","inReplyTo":"1329d238-e38a-7c8b-d468-500a0ae38bbb@gmail.com","subject":"Re: Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-18T03:05:22Z","receivedAt":"2021-07-18T03:05:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Blain wrote:\n> Le 2021-07-17 à 15:34, Felipe Contreras a écrit :\n> > Hello,\n> > \n> > Philippe Blain wrote:\n> >> Your recent clean-up of 'git pull --autostash' seems to unfortunately have made things\n> >> worse if the pull brings new files that conflict with existing untracked files,\n> >> which makes the pull abort,\n> >> and there are tracked files with modifications (so --autostash comes into play).\n> >>\n> >> Before your change, 'git pull --no-rebase --autostash' did *not* apply the autostash\n> >> after the pull failed, thus loosing modifications to tracked files (and it did not save the\n> >> stash entry !). 'git pull --rebase --autostash' correctly applied the autostash, but ended with\n> >> a strange \"error: could not detach HEAD\".\n> >>\n> >> After your change, both 'git pull --no-rebase --autostash' and 'git pull --rebase --autostash'\n> >> have the same buggy behaviour: they do not apply the autostash and do not save it in the stash list.\n> >>\n> >> I had already documented the old behaviour at [1]. Here, I copy my reproducer script\n> >> (save it as \"script\"):\n> > \n> > I cannot reproduce this. In my case the reproducer script never puts\n> > anything in the stash list.\n> \n> I tried again with GIT_CONFIG_GLOBAL=/dev/null on my end (and manually\n> setting GIT_AUTHOR_{NAME,EMAIL}) to be sure that my config was not playing\n> a role, and I still reproduce. Copying the output from my 1st email\n> (for --rebase, but it's the same thing for --no-rebase):\n> \n> \n> > ** ./script --rebase --autostash **\n> > \n> > ~~~\n> > + git status\n> > On branch master\n> > Your branch is up to date with 'origin/master'.\n> > \n> > Changes not staged for commit:\n> >   (use \"git add <file>...\" to update what will be committed)\n> >   (use \"git restore <file>...\" to discard changes in working directory)\n> >     modified:   file\n> > \n> > Untracked files:\n> >   (use \"git add <file>...\" to include in what will be committed)\n> >     other\n> > \n> > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> > + git pull --rebase --autostash\n> > remote: Enumerating objects: 4, done.\n> > remote: Counting objects: 100% (4/4), done.\n> > remote: Compressing objects: 100% (2/2), done.\n> > remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0\n> > Unpacking objects: 100% (3/3), 283 bytes | 94.00 KiB/s, done.\n> > From /Users/Philippe/Code/GIT-devel/BUGS/ggg-759-pull-autotash-untracked/test\n> >    4ebab2f..fc7a169  master     -> origin/master\n> > Updating 4ebab2f..fc7a169\n> > Created autostash: cfd51b5\n> > error: The following untracked working tree files would be overwritten by merge:\n> >     other\n> > Please move or remove them before you merge.\n> > Aborting\n> \n> Here is the bug: we should see \"Applied autostash\" after \"Aborting\". The 'git status'\n> below is to verify that the autostash was indeed not applied, and the\n> 'git stash list' was to check if the autostash was at least available\n> in the stash list (it's not).\n\nAhh, I thought you expected `git stash list` to show something. If this\nis the bug then yeah, I can reproduce.\n\n> > + git status\n> > On branch master\n> > Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.\n> >   (use \"git pull\" to update your local branch)\n> > \n> > Untracked files:\n> >   (use \"git add <file>...\" to include in what will be committed)\n> >     other\n> > \n> > nothing added to commit but untracked files present (use \"git add\" to track)\n> > + git stash list\n> > # empty!\n> > ~~~ \n> \n> Back to your reply:\n> \n> > \n> > Moreover, this is not an issue of `git pull`, but `git merge`.\n> > \n> > I can reproduce the problem that the modifications are lost like this:\n> > \n> >    git init test\n> >    (\n> >      cd test\n> >      date >> file\n> >      git add file\n> >      git commit -m 'add file'\n> >      date >> other\n> >      git add other\n> >      git commit -m 'add other'\n> >      git checkout -b topic @~\n> >      date >> other\n> >      date >> file\n> >      git status\n> >      git \"$@\" master\n> >      git status\n> >      git stash list\n> >    )\n> > \n> > Running this with 'rebase --autostash' fails and nothing is put in the\n> > stash list, but the modifications to 'file' remain. I think this is the\n> > correct behavior.\n> \n> Yes. We see the following output:\n> \n>      Created autostash: 69775ee\n>      Applied autostash.\n>      Successfully rebased and updated refs/heads/topic.\n> \n> The code correctly applied the autostash after the rebase, so it's\n> normal it's not kept in the stash list. I agree it's the correct behaviour.\n\nGood.\n\n> > But with 'merge --autostash' the modifications to 'file' are lost. That\n> > is a bug, and it's already present in v2.32.\n> \n> That's also true. From what I understand it dates back to the introduction\n> of 'git merge --autostash'.\n\nYes, that's probably true.\n\n> > Do you agree?\n> \n> I agree that the bug with 'merge --autostash' was already present in v2.32.0.\n> But since your 340062243a (pull: cleanup autostash check, 2021-06-17),\n> 'git pull --rebase --autostash' calls 'git merge --autostash' in the fast-forward\n> case, and so we hit the bug, which was not the case before since the fast-forward\n> merge shortcut was skipped if '--autostash' was given for 'git pull --rebase'.\n\nYes we hit the bug with `git pull`, but the bug was there already when\npeople did `git merge`.\n\n> The fix I suggested in [1] seems to fix both cases, but as I wrote there\n> it still leaves two code paths that might trigger the bug. I'm not familiar\n> at all with the code for these two code paths, so I'm not ready to send\n> a formal patch; I thought I'd send the diff anyway if you or Denton (or anyone\n> else) wants to start from there.\n\nUnfortunately I'm not familiar with the `git merge` code either, I've\nonly been modifying the `git pull` code, so I would also be starting\nfrom scratch if I tried to fix that myself.\n\nBut I think that's where it should be fixed.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"431028","messageId":"4b20a7ad-5e1e-802f-021b-a4580e5138fe@gmail.com","threadId":"56120","inReplyTo":"60f39a72c9c8e_2fb208b3@natae.notmuch","subject":"Re: Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-07-23T12:17:07Z","receivedAt":"2021-07-23T12:17:11Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Felipe,\n\nLe 2021-07-17 à 23:05, Felipe Contreras a écrit :\n> Philippe Blain wrote:\n>> Le 2021-07-17 à 15:34, Felipe Contreras a écrit :\n> \n>> The fix I suggested in [1] seems to fix both cases, but as I wrote there\n>> it still leaves two code paths that might trigger the bug. I'm not familiar\n>> at all with the code for these two code paths, so I'm not ready to send\n>> a formal patch; I thought I'd send the diff anyway if you or Denton (or anyone\n>> else) wants to start from there.\n> \n> Unfortunately I'm not familiar with the `git merge` code either, I've\n> only been modifying the `git pull` code, so I would also be starting\n> from scratch if I tried to fix that myself.\n> \n> But I think that's where it should be fixed.\n\nI've just sent a patch series that fixes it:\n\nhttps://lore.kernel.org/git/pull.1002.git.1627042470.gitgitgadget@gmail.com/T/#t\n\nCheers,\n\nPhilippe.\n"},{"id":"431048","messageId":"60faea3498189_defb208e7@natae.notmuch","threadId":"56120","inReplyTo":"4b20a7ad-5e1e-802f-021b-a4580e5138fe@gmail.com","subject":"Re: Regression in 'git pull --rebase --autostash' since v2.32.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-23T16:11:32Z","receivedAt":"2021-07-23T16:11:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Blain wrote:\n> Le 2021-07-17 à 23:05, Felipe Contreras a écrit :\n> > Philippe Blain wrote:\n> >> Le 2021-07-17 à 15:34, Felipe Contreras a écrit :\n> > \n> >> The fix I suggested in [1] seems to fix both cases, but as I wrote there\n> >> it still leaves two code paths that might trigger the bug. I'm not familiar\n> >> at all with the code for these two code paths, so I'm not ready to send\n> >> a formal patch; I thought I'd send the diff anyway if you or Denton (or anyone\n> >> else) wants to start from there.\n> > \n> > Unfortunately I'm not familiar with the `git merge` code either, I've\n> > only been modifying the `git pull` code, so I would also be starting\n> > from scratch if I tried to fix that myself.\n> > \n> > But I think that's where it should be fixed.\n> \n> I've just sent a patch series that fixes it:\n> \n> https://lore.kernel.org/git/pull.1002.git.1627042470.gitgitgadget@gmail.com/T/#t\n\nThank you. I've reviewed the series and looks fine to me.\n\n-- \nFelipe Contreras"}]}