Steven Grimm wrote:
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@xxxxxxxxxxxxx>
---
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.
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/);
}
}
}
I'd be surprised if this would ever prune anything, as git doesn't throw out
objects reachable by reflog (or, I assume, any of the objects reachable from
objects reachable from reflog).
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
