Junio C Hamano <junkio@xxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> 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. :-) > 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! > > 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. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html