Re: HEAD's reflog entry for a renamed branch
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 26, 2017, 21:30 UTC
- Message-ID
- <xmqqk29h33w1.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170126211205.5gz3zsrptop7n34n@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 14 quoted lines
> It's unfortunate that there's no message. This is because the rename > calls delete_ref() under the hood, but that function doesn't take a > reflog message argument at all. It usually doesn't matter because > deleting the ref will also delete the reflog. > > But as your example shows, deletions _can_ get logged in the HEAD > reflog; the low-level ref code detects when HEAD points to the updated > ref and logs an entry there, too. > ... > I'd say there are two potential improvements: > > - delete_ref() should take a reflog message argument, in case it > updates the HEAD reflog (as a bonus, this will future-proof us for a > day when we might keep reflogs for deleted refs).
This sounds sensible.
Show 5 quoted lines
> - "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).
This one I care less (not in the sense that I prefer it not done, but in the sense that I do not mind it is left unfixed than the other one you pointed out).