(Please don't top-post on the list) On Wed, Nov 17, 2021 at 5:01 PM Waleed Khan <me@xxxxxxxxxxxxxxx> wrote: > > So what should users of the `reference-transaction` hook do in general? It sounds like we can never actually rely on the new value corresponding to the state of the reference on disk. Is that correct? I wish I had a good answer here, but unfortunately I don't. My comments are coming from a similar place: The end result of my own experiences and learnings trying to use "reference-transaction" for something. The dual backends, and the fact that "reference-transaction" receives _no hints_, as far as I'm aware, of what backend a callback is for, makes some use cases quite difficult in practice. It would be nice if there was an environment variable, or something, to indicate what backend a transaction was for. But for cases like this, where a ref is being "moved" between backends, the split nature of the backends, and the fact that each has its own separate transaction, makes working in a "simple" script, which has no more state than its current invocation, extremely difficult. Of course, since Git doesn't really have an ACID mechanism for atomically updating both "packed-refs" and loose ref files, trying to have a single reference transaction wouldn't really work either. > > I suppose if we want the real new value of the reference, we should always look it up freshly? If so, the githooks documentation should be updated. Currently, it has a remark on the validity when the old reference is zero, but not on the validity of the new reference. I'm not sure the "validity" of the new reference is the problem here. Both reference transactions _are_ giving you the correct new value; "packed-refs" is inserting "refs/heads/master" at e197d18, and the loose ref for it is being deleted. To me the difficulty isn't that the new value is _wrong_ (it's actually right), it's that, because there are two reference transactions and no shared context between them or hints as to what backend they're for, it's not really possible to put 2+2 together and realize that 4 is a ref being moved from loose to packed--but otherwise unchanged. Best regards, Bryan Turner
