Re: git symbolic-ref vs. reflog (vs. rebase)

[Jeff King <peff@peff.net>]

On Fri, Apr 29, 2011 at 10:51:31PM +0530, Csaba Henk wrote:

> > Yes, it is.  But you can choose to do:
> >
> >        $ git branch side
> >        $ git symoblic-ref -m "move to side" HEAD refs/heads/side
> >        $ git log --oneline -g HEAD@{0}
> >        05ddb9b HEAD@{0}: move to side
> >        e69de29 HEAD@{1}: commit (initial): first commit
> >
> > if you wanted to.
> 
> So do you think the following patch would be the correct fix for the
> rebase issue:
> 
> diff --git a/git-rebase.sh b/git-rebase.sh
> index cbb0ea9..10c1727 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -284,7 +284,7 @@ do
>                 head_name="$(cat "$dotest"/head-name)" &&
>                 case "$head_name" in
>                 refs/*)
> -                       git symbolic-ref HEAD $head_name ||
> +                       git symbolic-ref -m "rebase: aborting" HEAD
> $head_name ||
>                         die "Could not move back to $head_name"
>                         ;;
>                 esac

I count 2 uses of symbolic-ref without reflogs in git-rebase, one more
in git-rebase--interactive, and one in git-cvsexportcommit. Should all
be fixed to write a reflog entry?

The one in git-rebase.sh:move_to_original_branch even takes care to
write a reflog message when updating the ref. So the branch reflog has
an entry for the rebase being finished, but the HEAD reflog gets
nothing. Presumably it's OK because we're moving from the detached
version of some commit to seeing it on the branch.

What does a user expect? Personally I think it would be more readable to
see the extra entry. For example, this is from my current reflog:

  $ git log -g --oneline
  ...
  50d3062 HEAD@{23}: checkout: moving from jk/merge-one-file to 50d3062ab2cea4e999b8f3bafd211ff348bca600
  660fe6b HEAD@{24}: commit (amend): merge-one-file: fix broken merges with GIT_WORK_TREE
  ebad5e6 HEAD@{25}: commit (amend): merge-one-file: fix broken merges with GIT_WORK_TREE
  306f37e HEAD@{26}: rebase -i (pick): merge-one-file: fix broken merges with GIT_WORK_TREE
  0681894 HEAD@{27}: commit (amend): add tests for merge-index / merge-one-file
  77d4cba HEAD@{28}: cherry-pick
  50d3062 HEAD@{29}: checkout: moving from jk/merge-one-file to 50d3062ab2cea4e999b8f3bafd211ff348bca600
  ...

So reading in reverse order, I see that I started a rebase, which moved
us to a detached HEAD, then picked and amended some commits. And then
nothing, and suddenly I'm moving back from a branch to another detached
HEAD (I rebased again). It would be easier to follow if HEAD{23} were
actually:

  660fe6b HEAD{23}: rebase finished: returning to jk/merge-one-file

This feels a little nit-picky. I have to admit I don't try to follow
these sorts of reflogs all the time, so it's not like this is a pressing
issue. But when it comes to a user deciphering a broken state in their
repository, or trying to figure out which actions they took in a rebase
last week, the more entries we can give them, the better.

-Peff