| Message ID | pull.1002.git.1627042470.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | merge --autostash: apply autostash in more cases | expand |
Philippe Blain via GitGitGadget wrote: > This series aims to apply the stash created by 'git merge --autostash' in 2 > situations that were not covered by the code: > > 1. If the merge is fast-forward but the fast-forward operation fails - > PATCH 3/4 > 2. If the merge strategy completely fails to handle the merge (exit code 2) > - PATCH 4/4 > > The first 2 commits are small improvements that I noticed while implementing > the other two. > > I'm marking it [RFC] because I'm not 100% sure that trying to apply the > autostash in 3/4 and 4/4 is actually the best course of action (or if it > would be better to call 'save_autostash' instead). That's because: > > For 3/4 (fast-forward fails): I'm not sure if 'unpack_trees' (called by > 'checkout_fast_forward') is guaranteed to fail atomically, or it might fail > mid-way and leave the worktree unclean, in which case it might be better not > to apply the autostash, but just save it instead (and tell the user). In the > test case I'm adding, it does fail before starting to update the working > tree, but I'm not sure if it's always the case. I'm not familiar with unpack_trees, but sans that possibility the whole series looks fine to me.
This series aims to apply the stash created by 'git merge --autostash' in 2 situations that were not covered by the code: 1. If the merge is fast-forward but the fast-forward operation fails - PATCH 3/4 2. If the merge strategy completely fails to handle the merge (exit code 2) - PATCH 4/4 The first 2 commits are small improvements that I noticed while implementing the other two. I'm marking it [RFC] because I'm not 100% sure that trying to apply the autostash in 3/4 and 4/4 is actually the best course of action (or if it would be better to call 'save_autostash' instead). That's because: For 3/4 (fast-forward fails): I'm not sure if 'unpack_trees' (called by 'checkout_fast_forward') is guaranteed to fail atomically, or it might fail mid-way and leave the worktree unclean, in which case it might be better not to apply the autostash, but just save it instead (and tell the user). In the test case I'm adding, it does fail before starting to update the working tree, but I'm not sure if it's always the case. For 4/4 (merge strategy fails): Same reasoning: I'm not sure if all strategies (and even less user-supplied ones, which are not documented but kind of supported) are guaranteed to 'exit 2' before messing up the working tree. Philippe Blain (4): merge: add missing word "strategy" to a message Documentation: define 'MERGE_AUTOSTASH' merge: apply autostash if fast-forward fails merge: apply autostash if merge strategy fails Documentation/merge-options.txt | 3 ++- builtin/merge.c | 4 +++- t/t7600-merge.sh | 19 +++++++++++++++++++ 3 files changed, 24 insertions(+), 2 deletions(-) base-commit: d486ca60a51c9cb1fe068803c3f540724e95e83a Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1002%2Fphil-blain%2Fmerge-autostash-ff-fails-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1002/phil-blain/merge-autostash-ff-fails-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/1002