On Fri, Feb 17, 2017 at 06:41:32PM -0500, Kyle Meyer wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>
> [...]
>
> > Do we even want these "internal" delete_ref() invocations to be
> > logged in HEAD's reflog? I understand that this is inside the
> > implementation of renaming an old ref to a new ref, and reflog
> > message given to delete_ref() would matter only if the HEAD happens
> > to be pointing at old ref---but then HEAD will be repointed to the
> > new ref by somebody else [*1*] that called this function to rename
> > old to new and it _will_ log it.
>
> I know the discussion has developed further, but just a note that I
> think the last statement is inaccurate: currently, a rename will not be
> recorded in HEAD's log. "git branch -m" will show a renaming event in
> the new branch's log, but the only trace of the event in HEAD's log is
> the deletion entry with an empty message.
Right. I assumed Junio was talking about the hypothetical behavior we'd
want.
Your response did make me think of one other option: if we updated HEAD
_before_ writing the new ref, then it would automatically get the
"create" half of the rename. IOW, if the rename process were:
1. delete old; this writes a reflog to HEAD, per the magic
HEAD-detection in commit_ref_update().
2. update HEAD to point to new
3. re-create new; this uses the same magic to write a HEAD reflog.
That's probably a crazy path to go, though. Right now steps (1) and (3)
happen in a low-level function, and step (2) happens outside of it
completely. Arguably it would be good to change that, but I think we
want to think of (1) and (3) as an atomic operation. Putting more things
which might fail between them is a bad idea.
So I think your existing patches (modulo the review comments), plus the
"something like this" that I sent on top are probably a better end
state.
-Peff
