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

[Peter Baumann <waste.manager@gmx.de>]

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