Thread (20 messages) flat view 20 messages, 3 authors, 2017-02-25

Re: [PATCH 0/3] delete_ref(): support reflog messages

From: Jeff King <hidden>
Date: 2017-02-17 08:18:16

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. :)
quoted
  - "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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help