On Thu, Feb 16, 2017 at 10:57:57PM -0500, Kyle Meyer wrote:
> [Sorry for the slow response.]
No problem. The pace of open source varies wildly. :)
> > - "git branch -m" does seem to realize when we are renaming HEAD,
> > because it updates HEAD to point to the new branch name. But it
> > should probably insert another reflog entry mentioning the rename
> > (we do for "git checkout foo", even when "foo" has the same sha1 as
> > the current HEAD).
>
> I haven't worked out how to do this part yet. I'm guessing the change
> will involve modifying split_head_update().
>
> If this is added, should it be instead of, rather than in addition to,
> the deletion entry? If a "Branch: renamed ..." entry is present, it
> doesn't seem like the deletion entry is providing any additional
> information.
I think you could do an "instead of" that goes from sha1 X to X, and
just mentions the rename. Or you could add a second entry after the
delete that takes it from 0{40} back to X.
I suspect the latter is easier to do, and I doubt anybody would care
that much of the exact form. These entries aren't really doing anything
for reachability. They're just giving an audit log of what happened. So
I don't think anybody would really care unless they were debugging a
confusing situation by hand. And as long as there's enough information
to figure out what happened, they'll be happy.
-Peff