Re: [PATCH 2/2] git reflog expire

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 19, 2006, 10:40 UTC
Message-ID: <20061219104032.GB21324@spearce.org>
In-Reply-To: <7vhcvsry2c.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 8 quoted lines

> Shawn Pearce <spearce@spearce.org> writes:
> 
> > 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.  :-)

Show 15 quoted lines

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

Show 10 quoted lines

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

Show 5 quoted lines

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