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

Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit

From
EWEric Wong <normalperson@yhbt.net>
Date
Oct 5, 2007, 23:54 UTC
Message-ID
<20071005235453.GB16849@untitled>
In-Reply-To
<20071005001528.GA13029@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
Show 14 quoted lines
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling.  Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
> 
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
> 
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.

I'm not a fan of automatic gc in general, but I understand it can help new users. So as long as clueful users can easily disable it, then it's fine by me...

Show 20 quoted lines
>  git-svn.perl |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
>  			}
>  			command_noisy(@finish, $gs->refname);
>  			$last_rev = $cmt_rev;
> +
> +			# rebase will have made the just-committed revisions
> +			# unreachable; over time that can build up lots of
> +			# loose objects in the repo. prune is unsafe to run
> +			# concurrently but so is dcommit.
> +			command_noisy(qw/gc --auto --prune/);
>  		}
>  	}
>  }

This is better called outside of this loop. We now do a rebase after every revision committed (which gets us even more dangling commits); but we only want to call git-gc after everything is committed.

It'll be faster since git-gc is only invoked once, and if git-gc takes a very long time to repack, we won't have to worry about timing out a SVN network connection. It'll also reduce the window for somebody else to commit a conflicting change that'll cause dcommit to fail midway through.

As far as Peter's concerns for shared repositories go, I'm not sure...

I've never been comfortable with shared repositories myself (even in a pure git environment without git-svn) and always just preferred using full clones or copies[1] myself so I could rm -r any working directory and not worry about any other repositories relying on it.

[1] - I usually go about using cp -al + libflcow :)
-- 
Eric Wong
Previous: Peter Baumann
Message 10 of 10 in “Run garbage collection with loose object pruning after svn dcommit”
  1. 2/2 Run garbage collection with loose object pruning after svn dcommitSteven Grimm, Oct 5, 2007
  2. Andreas EricssonOct 5, 2007
  3. Johannes SchindelinOct 5, 2007
  4. Peter BaumannOct 5, 2007
  5. Steven GrimmOct 5, 2007
  6. 3/2 Document the fact that git-svn now runs git-gcSteven Grimm, Oct 5, 2007
  7. Peter BaumannOct 5, 2007
  8. Steven GrimmOct 5, 2007
  9. Peter BaumannOct 6, 2007
  10. Eric WongOct 5, 2007

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.