Re: git-filter-branch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 9, 2007, 08:58 UTC
Message-ID: <Pine.LNX.4.64.0708090954550.21857@racer.site>
In-Reply-To: <20070809063453.GA12602@glandium.org>

Hi,

On Thu, 9 Aug 2007, Mike Hommey wrote:

> What is supposed to be the usage() of git-fetch-branch ?
> 
> git-filter-branch itself says:
> git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]

This is an unfortunate left-over. The syntax described in the documentation should be right.

> while the documentation doesn't explicitely talk about DESTBRANCH,
> expect in the form of an hypothetical /newbranch/, that you obviously
> don't give to the command line.

Hmm.  I don't have time to look into this now, but the syntax is this:

	git filter-branch [<options>] [--] [<rev-options>]

Those refs that you give in the <rev-options> are rewritten. AFAIR the old values of the refs (if different) are written to refs/original/*.

Show 5 quoted lines

> And whereas git-filter-branch itself says there is such an argument,
> it actually doesn't take it, and doesn't seem to be hardwired to create
> a new branch instead of overwriting the current one.
> 
> So what is git-filter-branch supposed to be doing ?

To rewrite refs.

> As a side note, if it ever happens that git-filter-branch can create a
> new branch, it might be nice to have each commit on the branch to have
> the original commit as parent, as well as its branch parent, so that
> they are seen as merges.

No, this will not happen. Filter-branch is meant to clean up branches, so it will rewrite the commits. However, you might be able to hack something in a parent filter.

Ciao, Dscho