On 02/13/2015 10:53 PM, Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes: > >> Now back to the real world. Currently, if R is changed *through* a >> symbolic reference S, then the reflogs for both R and S are updated, but >> not the reflogs for any other symbolic references that might point at R. >> If R is changed directly, then no symref's reflogs are affected, except >> for the special case that HEAD's reflog is changed if it points directly >> at R. This limitation is a hack to avoid having to walk symrefs >> backwards to find any symrefs that might be pointing at R. > > Yup. > >> It might actually not be extremely expensive to follow symrefs >> backwards. Symbolic references cannot be packed, so we would only have >> to scan the loose references; we could ignore packed refs. But it would >> still be a lot more expensive than just updating one file. I don't know >> that it's worth it, given that symbolic references are used so sparingly. > > I personally do not think it is worth it. I further think that it > would be perfectly OK to do one of the following: > > - We only maintain reflogs for $GIT_DIR/HEAD; no other symrefs > get their own reflog, and we only check $GIT_DIR/HEAD when > updating refs/heads/* and no other refs for direct reference > (i.e. HEAD -> refs/something/else -> refs/heads/master symref > chain is ignored). > > - In addition to the above, we also maintain reflogs for > $GIT_DIR/refs/remotes/*/HEAD but support only when they > directly point into a remote tracking branch in the same > hierarchy. $GIT_DIR/refs/remotes/foo/HEAD that points at > $GIT_DIR/refs/remotes/bar/master is ignored and will get an > undefined behaviour.
Yes. The first is approximately the status quo, except that you would like explicitly to *suppress* creating reflogs for symbolic refs other than HEAD even if a reference is altered via the symbolic ref. The second makes sense, though I think reflogs for remote HEADs are far less useful than those for HEAD. So I think this is a low-priority project. >> I think that the rule about locks as expressed above can be carried over >> the the real world: >> >> We should hold the locks on exactly those references (symbolic >> or regular) whose reflogs we plan to change. We should acquire all >> of the locks before making any changes. > > Sure. I forgot to mention that if we want to retain lock-compatibility with older clients, then we *also* need to lock the reference pointed at by a symbolic ref when modifying the symbolic ref's reflog. This is often implied by the previous rule, but not when we reseat a symbolic reference or when we expire a symbolic reference's reflog. I will look at how hard this is to implement. If it is at all involved, then I might drop this patch from the current patch series and defer it to another one. Michael -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
