On 27 February 2018 at 22:30, Martin Ågren <martin.agren@xxxxxxxxx> wrote:
> If we return early, we forget to roll back the lockfile. Do so.
>
> Signed-off-by: Martin Ågren <martin.agren@xxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxxx/
