Re: [PATCH v2 00/21] refs backend reroll

On Tue, Jan 12, 2016 at 04:22:09PM -0800, Junio C Hamano wrote:

David Turner [off-list ref] writes:

quoted

This version incorporates many changes suggested by Michael Haggerty,
Junio, Jonathan Nieder, Eric Sunshine, and Jeff King. I think I have
addressed of the comments that were sent to me.  Those that I chose
not to incorporate, I responded to on the mailing list.

Thanks for all of the feed back so far.

Unfortunately this did not compile for me X-< and with a trivial
fix-up, I found that this overlaps with Peff's recent fixes to the
locking of symbolic refs.  So for today's integration run, I punted.

I still will push out this topic to the broken-out repository I keep
here:

    https://github.com/gitster/git

It's just 'pu' will not have this latest incarnation, but has the
older one.

I took a look at David's changes. The conflicts come from "refs:
resolve symbolic refs first". I'm not sure I fully understand all that
is going on in that patch, but it looks like after it, we are less
likely to handle ENOTDIR and d/f conflicts for symrefs, as we skip that
whole code path for REF_ISSYMREF.

The rest of the conflicts are related to the fact that all of the
initial resolution is pulled out of lock_ref_sha1_basic(), and the
caller is supposed to do it. So I think if create_symref() is going to
call lock_ref_sha1_basic(), as in my series, when combined with David's
it should also be calling dereference_symrefs(). That uses a
ref_transaction, which we don't have in create_symref() right now, but
it makes sense that we would ultimately want to push symref updates
through the same transaction/backend system.

So sorry, I don't have a quick resolution to this. I'm hoping David can
make more sense of it than I did.

-Peff