From: Felipe Contreras <felipe.contreras@gmail.com>
To: Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Cc: Denton Liu <liu.denton@gmail.com>,
Felipe Contreras <felipe.contreras@gmail.com>,
Philippe Blain <levraiphilippeblain@gmail.com>
Subject: RE: [PATCH 0/4] [RFC] merge --autostash: apply autostash in more cases
Date: Fri, 23 Jul 2021 11:10:40 -0500 [thread overview]
Message-ID: <60faea007b6ce_defb20871@natae.notmuch> (raw)
In-Reply-To: <pull.1002.git.1627042470.gitgitgadget@gmail.com>
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.
--
Felipe Contreras
prev parent reply other threads:[~2021-07-23 16:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 12:14 [PATCH 0/4] [RFC] merge --autostash: apply autostash in more cases Philippe Blain via GitGitGadget
2021-07-23 12:14 ` [PATCH 1/4] merge: add missing word "strategy" to a message Philippe Blain via GitGitGadget
2021-07-23 15:57 ` Felipe Contreras
2021-07-23 12:14 ` [PATCH 2/4] Documentation: define 'MERGE_AUTOSTASH' Philippe Blain via GitGitGadget
2021-07-23 16:00 ` Felipe Contreras
2021-07-23 12:14 ` [PATCH 3/4] merge: apply autostash if fast-forward fails Philippe Blain via GitGitGadget
2021-07-23 16:02 ` Felipe Contreras
2021-07-23 19:13 ` Junio C Hamano
2021-07-23 12:14 ` [PATCH 4/4] merge: apply autostash if merge strategy fails Philippe Blain via GitGitGadget
2021-07-23 19:22 ` Junio C Hamano
2021-07-23 16:10 ` Felipe Contreras [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60faea007b6ce_defb20871@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.