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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le 2021-07-17 à 11:29, Philippe Blain a écrit :
Hi Felipe,

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.

The change below seem to fix both cases:

diff --git a/builtin/merge.c b/builtin/merge.c
index a8a843b1f5..b2ad70c50a 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1560,6 +1560,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
 					  &head_commit->object.oid,
 					  &commit->object.oid,
 					  overwrite_ignore)) {
+			apply_autostash(git_path_merge_autostash(the_repository));
 			ret = 1;
 			goto done;
 		}


*But* from a quick audit of 'cmd_merge', there are still two code paths that
call 'create_autostash' but then fail to apply it before calling 'goto done':

1. the branch 'if (automerge_was_ok)' (line 1693)
2. the branch 'if (!best_strategy)' (line 1704)


Cheers,
Philippe.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux