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

From: Jeff King <peff@peff.net>
Date: Apr 30, 2011, 04:13 UTC
Message-ID: <20110430041312.GA5287@sigill.intra.peff.net>
In-Reply-To: <BANLkTi=yDECQs=mVkEfrkrFfy0dgFf4U3Q@mail.gmail.com>

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

Show 27 quoted lines

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