David Turner <dturner@xxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html