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