git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] git reflog expire

From
Shawn Pearce <spearce@spearce.org>
Date
Dec 19, 2006, 09:08 UTC
Message-ID
<20061219090851.GH2511@spearce.org>
In-Reply-To
<7v64c8thr4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
Show 16 quoted lines
> This prepares a place to collect reflog management subcommands,
> and implements "expire" action.
> 
> 	$ git reflog expire --dry-run \
> 		--expire=4.weeks \
> 		--expire-lost=1.week \
> 		refs/heads/master
> 
> The expiration uses two timestamps: --expire and --expire-lost.
> Entries older than expire time (defaults to 90 days), and
> entries older than expire-lost time (defaults to 30 days) and
> talk about a commit that has been rewound and made unreachable
> from the current tip of the ref are removed from the reflog.
> 
> The parameter handling is still rough, but I think the
> core logic for expiration is already sound.
I agree, this looked pretty good to me.

I disagree with the option name '--expire-lost'. The way I initially read that was:

    --expire-lost: ok, if the object was already pruned out of
    the ODB and the reflog entry is older than 1 week, remove it;
    otherwise keep it in case the user could manually recover the
    object from another ODB.

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

Perhaps --expire-lost should default to just be 1/3 of the time of --expire, whatever --expire is: 90 day default or command line value?

I'm thinking that we may want the 'expire' subcommand to simply be implied by '--expire' instead. Basically my rational here is I want to be able to do 'git reflog HEAD' to view the reflog associated with my current branch, effectively seeing the Git operational history of this branch. Or 'git reflog a b' to see the operational history of two branches with their reflogs interleaved based on entry time.

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

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, e.g.:

  $ git reflog --expire=4.weeks --expire-lost=1.week master
  would expire ...
  would expire ...
  would expire ...
  Restart with '--prune' to expire the above log entries and commits.
  $ git reflog --expire=4.weeks --expire-lost=1.week master --prune
?

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

*1* Yes, I know, I'll do bash completion for this command too.  ;-)
Previous: Junio C HamanoNext: Junio C Hamano
Message 21 of 28 in “What's cooking in git.git (topics)”
  1. Junio C HamanoDec 16, 2006
  2. Jakub NarebskiDec 16, 2006
  3. Junio C HamanoDec 17, 2006
  4. Yann DirsonDec 17, 2006
  5. Josef WeidendorferDec 17, 2006
  6. Brian GernhardtDec 17, 2006
  7. Shawn PearceDec 17, 2006
  8. revision: introduce ref@{N..M} syntax.Junio C Hamano, Dec 17, 2006
  9. Linus TorvaldsDec 17, 2006
  10. Junio C HamanoDec 17, 2006
  11. Andy ParkinsDec 17, 2006
  12. Junio C HamanoDec 18, 2006
  13. Andy ParkinsDec 18, 2006
  14. Shawn PearceDec 18, 2006
  15. 1/2 add for_each_reflog_ent() iteratorJunio C Hamano, Dec 18, 2006
  16. 2/2 Protect commits recorded in reflog from pruning.Junio C Hamano, Dec 18, 2006
  17. Shawn PearceDec 18, 2006
  18. Junio C HamanoDec 19, 2006
  19. 1/2 Move in_merge_bases() to commit.cJunio C Hamano, Dec 19, 2006
  20. 2/2 git reflog expireJunio C Hamano, Dec 19, 2006
  21. Shawn PearceDec 19, 2006
  22. Junio C HamanoDec 19, 2006
  23. Shawn PearceDec 19, 2006
  24. Linus TorvaldsDec 19, 2006
  25. Junio C HamanoDec 20, 2006
  26. Linus TorvaldsDec 20, 2006
  27. Shawn PearceDec 19, 2006
  28. Junio C HamanoDec 19, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.