Re: [PATCH v2] refs: implement reference transaction hook

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 3, 2020, 18:03 UTC
Message-ID: <xmqq7dworpqy.fsf@gitster.c.googlers.com>
In-Reply-To: <CAFQ2z_OSfsKKkOu_wKEAWi-Zihp4g265jtmXzteaU=BQZohEAQ@mail.gmail.com>

Han-Wen Nienhuys <hanwen@google.com> writes:

Show 6 quoted lines

>> +For each reference update that was added to the transaction, the hook
>> +receives on standard input a line of the format:
>> +
>> +  <old-value> SP <new-value> SP <ref-name> LF
>
> Does this work for symrefs as well? Should it?

That's a good question.

I am assuming that you are asking about updating the value of the underlying ref the symbolic ref points at (i.e. <ref-name> would be "HEAD" and old- and new-value are commits at the tip of the branch that is currently checked out), and not about repointing the symbolic ref to a different underlying ref. I suspect we do not want to. In such a case, we'd have a separate "refs/heads/master moved from old to new" record anyway, so we probably should not even talk about symbolic refs when we report "a ref got updated to point a different object" in the above format.

And obviously the above format cannot talk about repointing HEAD to a different branch (well, it can in a sense that old and new branch both would have some object name that can be filled in the old- and new-value fields, but the record misses the most interesting part of the "branch switching" without the actual old and new refnames), so there must be another format that allows us to report such an event.

    "Sym" SP <old-refname> SP <new-refname> SP <symbolic-ref-name> LF

or something like that, so that

	$ git checkout next

may yield

    "Sym" SP "refs/heads/master" SP "refs/heads/next" SP "HEAD"

if we originally were on the 'master' branch. Obviously we need a way to represent different kinds of transition, like (1) a new symbolic ref has been created, pointing at some underlying ref (which may or may not exist), (2) an existing ref that pointed directly at an object now has become a symbolic ref, (3) a symbolic ref stopped pointing at a ref and now points directly at an object, and (4) a symbolic ref has been removed.

Both (1) and (4) would be a trivial variation of the above format, I guess, using some special token to denote void (say, we'd use an empty string for that):

    "Sym" "" SP <new-refname> SP <symbolic-ref-name> LF
    "Sym" <old-refname> SP "" SP <symbolic-ref-name> LF

(2) and (3) are interesting. We could represent them as two separate operations inside the same transaction, e.g.

    "Sym" "refs/heads/master" SP "" SP "HEAD" LF
    "0{40}" SP "b3d7a52fac39193503a0b6728771d1bf6a161464" SP "HEADD" LF

or we'd need to invent different type of record to represent such "detaching" and "reattaching" events.