All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Shawn Pearce <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] git reflog expire
Date: Tue, 19 Dec 2006 02:15:39 -0800	[thread overview]
Message-ID: <7vhcvsry2c.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20061219090851.GH2511@spearce.org> (Shawn Pearce's message of "Tue, 19 Dec 2006 04:08:51 -0500")

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?

> I'm thinking that we may want the 'expire' subcommand to simply be
> implied by '--expire' instead.

After coding this, my conclusion is the same as yours, but
reasoning behind it is slightly different.

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.

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

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.

> I would also say maybe we want to make --dry-run the default, with
> a final message which tells the user that if they really want to
> make it possible to throw away the commits printed above then
> restart the expire operation.

I am moderately negative on that.  Nobody does it like that;
prune, branch -d, tag -d,...

> I'd like to take a stab at the log display code for the reflog
> command, but I'd also really like to port forward (aka rewrite)
> that mmap window code I keep saying I'll work on, but never quite
> seem to do...

After today's pread() thing, I was also wondering about that too
;-).

  reply	other threads:[~2006-12-19 10:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-16 23:10 What's cooking in git.git (topics) Junio C Hamano
2006-12-16 23:29 ` Jakub Narebski
2006-12-17  0:19   ` Junio C Hamano
2006-12-17 17:35   ` Yann Dirson
2006-12-17 23:38     ` Josef Weidendorfer
2006-12-17  4:35 ` Brian Gernhardt
2006-12-17  4:42   ` Shawn Pearce
2006-12-17  6:46   ` [PATCH] revision: introduce ref@{N..M} syntax Junio C Hamano
2006-12-17 18:14     ` Linus Torvalds
2006-12-17 19:38       ` Junio C Hamano
2006-12-17 23:41 ` What's cooking in git.git (topics) Andy Parkins
2006-12-18  8:09   ` Junio C Hamano
2006-12-18  9:17     ` Andy Parkins
2006-12-18  9:33       ` Shawn Pearce
2006-12-18  9:40 ` [PATCH 1/2] add for_each_reflog_ent() iterator Junio C Hamano
2006-12-18  9:42 ` [PATCH 2/2] Protect commits recorded in reflog from pruning Junio C Hamano
2006-12-18 14:08   ` Shawn Pearce
2006-12-19  1:22     ` Junio C Hamano
2006-12-19  8:25       ` [PATCH 1/2] Move in_merge_bases() to commit.c Junio C Hamano
2006-12-19  8:25       ` [PATCH 2/2] git reflog expire Junio C Hamano
2006-12-19  9:08         ` Shawn Pearce
2006-12-19 10:15           ` Junio C Hamano [this message]
2006-12-19 10:27             ` Shawn Pearce
2006-12-19 23:29               ` Linus Torvalds
2006-12-20  0:34                 ` Junio C Hamano
2006-12-20  0:58                   ` Linus Torvalds
2006-12-19 10:40             ` Shawn Pearce
2006-12-19 11:08               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vhcvsry2c.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.