Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 9, 2007, 10:37 UTC
Message-ID: <Pine.LNX.4.64.0710091133580.4174@racer.site>
In-Reply-To: <20071008163701.GA5868@thunk.org>

Hi,

On Mon, 8 Oct 2007, Theodore Tso wrote:

Show 15 quoted lines

> On Mon, Oct 08, 2007 at 10:36:50AM -0400, J. Bruce Fields wrote:
> > Having it by default leave these backups around, even when everything
> > succeeds, makes for unnecessary cleanup work in the normal case, and is
> > inconsistent with the behavior of other git commands that destroy or
> > rewrite history.
> 
> I think what makes git-filter-branch different is that you can change a 
> large amount of history with git-filter-branch, including large numbers 
> of tags, etc.  The reflog is quite sufficient to recover from a screwed 
> up "git commit --amend".
>
> [...]
>
> But I don't think the reflog is going to be sufficient given the kinds 
> of changes that git-filter-branch can potentially do to your repository.

FWIW after reading Bruce's reasoning, I tend towards having no "backups" by default (I say "backups", since they are _only_ written when the respective branch has changed).

And I do not think that the config variable is a good approach; if you want backups or not is a per-case decision. So your proposal would only result in even more confusion.

My preference ATM is to write nothing per default, but only when --original <namespace> was given.

Ciao, Dscho