Junio C Hamano [off-list ref] wrote:

Shawn Pearce [off-list ref] writes:

quoted

Of course that's not what the code does, because if either the
old or the new object is no longer in the ODB you are pruning away
the log entry.  I cannot however come up with a better name than
--expire-lost.  :-(

How about --expire-unreachable?

That actually does make more sense.  Those commits are what we would
traditionally have called unreachable commits, or dangling commits.
Hmm.  Flip a coin.  I'm probably as bad at UI as you are.  :-)
 

To have 'expire' action as a subcommand to 'git-reflog' is from
implementor's point of view, and is a horrible organization from
the UI standpoint.  To the end users, it may be easier to have a
single 'git-gc' command that runs these commands with reasonable
set of defaults:

  - rerere gc
  - reflog expire --all
  - (possibly) repack -a -d
  - prune

If we go that route, it probably is not even necessary to
advertise that 'expire' is a subcommand of reflog.  The users
would not run it from the command line; it is an implementation
detail of 'git-gc' command.

Yes!  I agree with you completely here.  I'd also include 'pack-refs
--prune' to your list above, at least for refs/tags.  Those suckers
can eat up a lot of disk, slow down viualizers, and well, just
don't change.  Pack 'em!

quoted

Needing a subcommand like 'git reflog show HEAD' is just a lot
of typing[*1*].

I am very interested in seeing how 'git reflog show HEAD' would
show the reflog entries.  I've tried showing it just like log
family shows (it is reasonably easy; you build the list of revs
out of reflog entries and feed them to 'git-show' machinery),
and while it works, it is unusable for the purpose of seeing
which ones are the lost ones (amended commits and rebased branch
remnants).

At this point I'm going to wind up getting less than 4 hours of
sleep tonight (I'll be lucky if I get 3).  So I'm just going to skip
trying to draft out what I might want this to look like right now.
I'll try to sketch out a dump by hand from a couple of my own reflogs
and post 'em later tonight.  Ugh.  Tonight.  Its Tuesday already.
My body still thinks its Monday.

The best I came up with is still my "show-branch --reflog" so
far.  You really need to show not just the commit title but how
they topologically relate to the commits on the surviving
branch, and I think having something graphical or semi-graphical
is a must.

Probably right.  But I can't make heads or tails out of that
output for just one topic branch whose reflog consists of only
the following:

  $ cut -f2 .git/logs/refs/heads/sp/mapwin 
  checkout: Created from origin^0
  am: Create read_or_die utility routine.
  reset --hard 106d710b
  am: Create read_or_die utility routine.
  reset --hard 
  rebase: Create read_or_die utility routine.

`show-branch --reflog --topics sp/mapwin` prints much shorter output
and almost says something useful, but not really.

--