Re: Re* [BUG] Index.lock error message regression in git 2.11.0

Junio C Hamano writes: > ... > I would not be surprised if some existing calls to hold_lock*() > functions that pass die_on_error=0 need to be updated to pass > LOCK_SILENT_ON_ERROR, and when this fix is taken alone, it may look > like a regression, but we are better off

Re* [BUG] Index.lock error message regression in git 2.11.0

Junio C Hamano writes: > Perhaps the attached would fix it (not even compile tested, though)? > > I would prefer to make 0 to mean "show error but return -1", 1 to > mean "die on error", and 2 to mean "be silent and return -1 on > error", though. Asking to be silent should be

Re: [BUG] Index.lock error message regression in git 2.11.0

Robbie Iannucci writes: > I just upgraded to 2.11.0 from 2.10.2, and I noticed that some > commands no longer print an error message when the `index.lock` file > exists (such as `git merge --ff-only`). > > It appears this bug was introduced in >

Re: [BUG] Index.lock error message regression in git 2.11.0

Apparently I'm not supposed to send attachments >_<. Here's the script in non-attachement form: #!/bin/bash make -j 8 2>&1 > /dev/null if [[ $? != 0 ]]; then # skip this version exit 125 fi git=`realpath ./git` rm -rf .test_repo || true mkdir .test_repo cd .test_repo $git init

[BUG] Index.lock error message regression in git 2.11.0

Hello, I just upgraded to 2.11.0 from 2.10.2, and I noticed that some commands no longer print an error message when the `index.lock` file exists (such as `git merge --ff-only`). It appears this bug was introduced in 55f5704da69d3e6836620f01bee0093ad5e331e8 (sequencer: lib'ify