Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs

[Junio C Hamano <gitster@pobox.com>]

David Turner <dturner@twopensource.com> writes:

> OK, here's my current best idea:
>
> 1. A "pseudoref" is an all-caps file in $GIT_DIR/ that always contains
> at least a SHA1.  CHERRY_PICK_HEAD and REVERT_HEAD are examples. Because
> HEAD might be a symbolic ref, it is not a pseudoref. 
>
> Refs backends do not manage pseudorefs.  Instead, when a pseudoref (an
> all-caps ref containing no slashes) is requested (e.g. git rev-parse
> FETCH_HEAD) the generic refs code checks for the existence of that
> file and if it exists, returns immediately without hitting the backend.
> The generic code will refuse to allow updates to pseudorefs.
>
> 2. The pluggable refs backend manages all refs other than HEAD.
>
> 3. The "files" backend always manages HEAD.  This allows for a reflog
> and for HEAD to be a symbolic ref.
>
> The major complication here is ref transactions -- what if there's a
> transaction that wants to update e.g. both HEAD and refs/heads/master?

An update to the current branch (e.g. "git commit") does involve at
least update to the reflog of HEAD, the current branch somewhere in
refs/heads/ and its log, so it is not "what if" but is a norm [*1*].

>
> It may be the case that this never happens; I have not actually audited
> the code to figure it out.  If someone knows for sure that it does not
> happen, please say so. But assuming it does happen, here's my idea:
>
> If the refs backend is the files backend, we can simply treat HEAD like
> any other ref.
>
> If the refs backend is different, then the refs code needs to hold a
> files-backend transaction for HEAD, which it will commit immediately
> after the other transaction succeeds.  We can stick a pointer to the
> extra transaction in the generic struct ref_transaction, which (as
> Michael Haggerty suggests) specific backends will extend.
>
> A failure to commit either transaction will be reported as a failure,
> and we'll give an additional inconsistent state warning if the main
> transaction succeeds but the HEAD transaction fails.

Yeah, I was thinking along those lines, too.  Thanks for clearly
writing it down.

> What do other folks think?

Me too ;-)


[Footnote]

*1* But that is not a complaint; I do not have a better idea myself
either.