On Mon, Jan 16, 2017 at 06:17:29PM -0500, Kyle Meyer wrote:
> I noticed that, after renaming the current branch, the corresponding
> message in .git/logs/HEAD is empty.
>
> For example, running
>
> $ mkdir test-repo
> $ cd test-repo
> $ git init
> $ echo abc >file.txt
> $ git add file.txt
> $ git commit -m"Add file.txt"
> $ git branch -m master new-master
Thanks for providing a simple reproduction recipe.
> resulted in the following reflogs:
>
> $ cat .git/logs/refs/heads/new-master
> 00000... 68730... Kyle Meyer <kyle@xxxxxxxxxx> 1484607020 -0500 commit (initial): Add file.txt
> 68730... 68730... Kyle Meyer <kyle@xxxxxxxxxx> 1484607020 -0500 Branch: renamed refs/heads/master to refs/heads/new-master
>
> $ cat .git/logs/HEAD
> 00000... 68730... Kyle Meyer <kyle@xxxxxxxxxx> 1484607020 -0500 commit (initial): Add file.txt
> 68730... 00000... Kyle Meyer <kyle@xxxxxxxxxx> 1484607020 -0500
>
> I expected the second line of .git/logs/HEAD to mirror the second line
> of .git/logs/refs/heads/new-master. Are the empty message and null sha1
> in HEAD's entry intentional?
The null sha1 is correct, I think. The branch we were on went away, and
we use the null sha1 to indicate "no value" in both the creation and
deletion cases.
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.
You can see the same thing with a simpler example:
$ git init
$ git commit -m foo --allow-empty
$ git update-ref -d refs/heads/master
$ cat .git/logs/HEAD
00000... 8ffd1... Jeff King <peff@xxxxxxxx> 1485464779 -0500 commit (initial): foo
8ffd1... 00000... Jeff King <peff@xxxxxxxx> 1485464787 -0500
This doesn't come up much because most porcelain commands will refuse to
delete the current branch (notice I had to use "update-ref" and not
"branch -d").
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).
- "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).
-Peff