Re: [PATCH 3/5] merge-recursive: always roll back lock in `merge_recursive_generic()`
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- Feb 28, 2018, 11:02 UTC
- Message-ID
- <CAN0heSqmWAN=rCO8busGtb0xNPiB5H_jkL664qH8xasPq1Sy0A@mail.gmail.com>
- In-Reply-To
- <b19db05a8d8a98977788c04908134915eebc86a3.1519763396.git.martin.agren@gmail.com>
On 27 February 2018 at 22:30, Martin Ågren <martin.agren@gmail.com> wrote:
Show 23 quoted lines
> If we return early, we forget to roll back the lockfile. Do so.
>
> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
> ---
> merge-recursive.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index cc5fa0a949..7345125691 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -2198,8 +2198,10 @@ int merge_recursive_generic(struct merge_options *o,
> hold_locked_index(&lock, LOCK_DIE_ON_ERROR);
> clean = merge_recursive(o, head_commit, next_commit, ca,
> result);
> - if (clean < 0)
> + if (clean < 0) {
> + rollback_lock_file(&lock);
> return clean;
> + }
>
> if (active_cache_changed &&
> write_locked_index(&the_index, &lock, COMMIT_LOCK))This is incomplete. If "!active_cache_changed", this function fails to roll back the lock. I'll reroll this series.
This also highlights the point Peff made in [1] about how that "active_cache_changed &&" can be confusing. I'll look into the added or extended API he proposed, although perhaps not as part of the reroll.
Martin
[1] https://public-inbox.org/git/20180227214430.GC6899@sigill.intra.peff.net/