Re: What's cooking in git.git (Dec 2016, #05; Mon, 19)

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Dec 27, 2016, 17:04 UTC
Message-ID: <afd95065-d076-b962-8337-b87008b9f894@alum.mit.edu>
In-Reply-To: <xmqq37hjmow0.fsf@gitster.mtv.corp.google.com>

On 12/20/2016 01:21 AM, Junio C Hamano wrote:

Show 28 quoted lines

> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
> 
> The second (rather large) batch of topics have been merged to
> 'master'.  Please test and catch possible regressions early.
> 
> You can find the changes described here in the integration branches
> of the repositories listed at
> 
>     http://git-blame.blogspot.com/p/git-public-repositories.html
> 
> --------------------------------------------------
> [Graduated to "master"]
> 
> [...]
> * jc/lock-report-on-error (2016-12-07) 3 commits
>   (merged to 'next' on 2016-12-13 at cb6c07ee92)
>  + lockfile: LOCK_REPORT_ON_ERROR
>  + hold_locked_index(): align error handling with hold_lockfile_for_update()
>  + wt-status: implement opportunisitc index update correctly
> 
>  Git 2.11 had a minor regression in "merge --ff-only" that competed
>  with another process that simultanously attempted to update the
>  index. We used to explain what went wrong with an error message,
>  but the new code silently failed.  The error message has been
>  resurrected.

Sorry I didn't notice this earlier, but the `LOCK_REPORT_ON_ERROR` constant introduced by

    3f061bf "lockfile: LOCK_REPORT_ON_ERROR", 2016-12-07

sets that constant to the value 2, which is the same value set for the existing constant `LOCK_NO_DEREF`. Both constants define bits that can be set in the `flags` argument of `hold_lock_file_for_update()`, so one of these values needs to be changed.

Michael