From: Peter Baumann Date: Sat, 06 Oct 2007 08:15:52 GMT Subject: Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit Message-ID: <20071006081552.GF4797@xp.machine.xx> In-Reply-To: <470678ED.8050407@midwinter.com> On Fri, Oct 05, 2007 at 10:48:29AM -0700, Steven Grimm wrote: > Peter Baumann wrote: >> That's new to me. Glancing over git-commit.sh, I could only find a >> 'git-gc --auto', but no prune. I am not against doing a 'git gc --auto', >> but I am against the --prune, because this could make shared >> repositories unfunctional. >> > > Does anyone run "git svn dcommit" from a shared repository? That is the > only command that will trigger this code path. > > Given that you lose all the svn metadata if you do "git clone" (or "git > clone -s") on a git-svn-managed repository, it's not clear to me that > anyone would ever be bitten by this. Counterexamples welcome, of course. > > How would you feel about a separate config option to specifically enable > auto-pruning, and having "git svn clone" set that option by default? > Presumably anyone who is setting up a shared git-svn repository will be up > to the task of disabling the option. > Sorry, I looked at 'git commit' (as you said in your mail) and not 'git-svn dcommit'. Looking now at git-svn, I could see the there is only done a git-repack if the user *explicitly* asked for it on the cmdline specifying --repack. For this repack run, the default parameter includes -d and no --prune, so I do not think that we are doing a --prune run if we where not _explicitly_ asked for it. As I said, I am totaly fine with doing a 'git-gc --auto', but I am a little worried about the --prune. We advertise everywhere that GIT adds only new content/objects/data to the repository and *never* deletes anything itself in the repo and now you want to do a --prune, wich obviously *does* delete data behind the users back in a dcommit/fetch operation, which no one would think of that these commands do have anything in common with deleting data. And this worries me. -Peter