On 13.05.16 14:33, Michael Haggerty wrote:
> Torsten, thanks for the report. Peff, thanks for the analysis.
I didn't follow all the details.
The new "pu" passes with no errors on all of my test systems :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
On Fri, May 13, 2016 at 02:33:20PM +0200, Michael Haggerty wrote:
> The problem in this case is a misguided call to
> verify_refname_available_dir() in the case that read_raw_ref() fails
> with ENOENT. In that case it is not possible for there to be a conflict
> with another loose reference, becau
On 05/12/2016 10:25 AM, Jeff King wrote:
> On Thu, May 12, 2016 at 03:45:28AM -0400, Jeff King wrote:
>
>> So I'd expect us to hit that lock_ref_for_update() for each of the new
>> refs. But then we end up in verify_refname_available_dir(), which wants
>> to read all of the loose refs again. So we
On Thu, May 12, 2016 at 03:45:28AM -0400, Jeff King wrote:
> So I'd expect us to hit that lock_ref_for_update() for each of the new
> refs. But then we end up in verify_refname_available_dir(), which wants
> to read all of the loose refs again. So we end up with a quadratic
> number of calls to re
On Fri, May 06, 2016 at 06:14:10PM +0200, Michael Haggerty wrote:
> This makes use of a new function, lock_ref_raw(), which is analogous to
> read_ref_raw(), but acquires a lock on the reference before reading it.
Minor nit: the new function is actually called lock_raw_ref(). I don't
care which i
Before committing ref updates, split symbolic ref updates into two
parts: an update to the underlying ref, and a log-only update to the
symbolic ref. This ensures that both references are locked correctly
during the transaction, including while their reflogs are updated.
Similarly, if the referenc
6 matches
Mail list logo
