From: Phillip Wood <[email protected]> Date: Wed, 15 Nov 2017 10:41:25 +0000
If the index cannot be locked in do_recursive_merge(), issue an error message and go on to the error recovery codepath, instead of dying. When the commit cannot be picked, it needs to be rescheduled when performing an interactive rebase, but just dying there won't allow that to happen, and when the user runs 'git rebase --continue' rather than 'git rebase --abort', the commit gets silently dropped. Signed-off-by: Phillip Wood <[email protected]> --- * I've queue this, taking input from responses by Dscho and Martin. sequencer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index 332a383b03..10924ffd49 100644 --- a/sequencer.c +++ b/sequencer.c @@ -438,7 +438,8 @@ static int do_recursive_merge(struct commit *base, struct commit *next, char **xopt; static struct lock_file index_lock; - hold_locked_index(&index_lock, LOCK_DIE_ON_ERROR); + if (hold_locked_index(&index_lock, LOCK_REPORT_ON_ERROR) < 0) + return -1; read_cache(); -- 2.15.0-360-gf2497ca0e5
