Re: HEAD's reflog entry for a renamed branch

[Jeff King]

On Thu, Jan 26, 2017 at 01:30:54PM -0800, Junio C Hamano wrote:

> >   - "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).

I wondered if it might affect how "git checkout -" works. But that
feature looks for reflogs like "checkout: moving from X to Y" to know to
move back to X.  So we are fine here. Even though the HEAD reflog does
not show us going _to_ new-master, we would see it in a later entry as
"from new-master to Y". What we are missing is "rename from master to
new-master", but that entry does not matter. There is no "master" to
go back to anymore. :)

-Peff

Re: HEAD's reflog entry for a renamed branch

[Junio C Hamano]

Jeff King  writes:

> 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.

>   - "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).

Re: HEAD's reflog entry for a renamed branch

[Jeff King]

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
>0... 68730... Kyle Meyer  1484607020 -0500commit 
> (initial): Add file.txt
>68730... 68730... Kyle Meyer  1484607020 -0500Branch: 
> renamed refs/heads/master to refs/heads/new-master
> 
>$ cat .git/logs/HEAD
>0... 68730... Kyle Meyer  1484607020 -0500commit 
> (initial): Add file.txt
>68730... 0... Kyle Meyer  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
  0...  8ffd1... Jeff King  1485464779 -0500 commit 
(initial): foo
  8ffd1...  0... Jeff King  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

HEAD's reflog entry for a renamed branch

[Kyle Meyer]

Hello,

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

resulted in the following reflogs:

   $ cat .git/logs/refs/heads/new-master
   0... 68730... Kyle Meyer  1484607020 -0500  commit 
(initial): Add file.txt
   68730... 68730... Kyle Meyer  1484607020 -0500  Branch: 
renamed refs/heads/master to refs/heads/new-master

   $ cat .git/logs/HEAD
   0... 68730... Kyle Meyer  1484607020 -0500  commit 
(initial): Add file.txt
   68730... 0... Kyle Meyer  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?

--
Kyle