git-filter-branch

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

> 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/*.

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

> On Thu, Aug 09, 2007 at 09:58:27AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 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/*.
> 
> In the description in the manpage:
>    Lets you rewrite git revision history by creating a new branch from
>    your current branch, applying custom filters on each revision.
>    (...)
>    The command takes the new branch name as a mandatory argument and the
>    filters as optional arguments
> 
> And in example:
>    Now, you will get the rewritten history saved in the branch newbranch
>    (your current branch is left untouched).
> 
> I must say this is a feature that would actually be nice to have...

> > > 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.
> 
> That would need the commit id for the original commit being treated at the
> time, which I don't think is available in parent filters...

> > In the description in the manpage:
> >    Lets you rewrite git revision history by creating a new branch from
> >    your current branch, applying custom filters on each revision.
> >    (...)
> >    The command takes the new branch name as a mandatory argument and the
> >    filters as optional arguments
> > 
> > And in example:
> >    Now, you will get the rewritten history saved in the branch newbranch
> >    (your current branch is left untouched).
> > 
> > I must say this is a feature that would actually be nice to have...
> 
> To compare with the old one?  Use reflogs:
> 
> 	git filter-branch --some-option master
> 	git diff master@{1}..master

> On Thu, Aug 09, 2007 at 10:19:20AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > In the description in the manpage:
> > >    Lets you rewrite git revision history by creating a new branch from
> > >    your current branch, applying custom filters on each revision.
> > >    (...)
> > >    The command takes the new branch name as a mandatory argument and the
> > >    filters as optional arguments
> > > 
> > > And in example:
> > >    Now, you will get the rewritten history saved in the branch newbranch
> > >    (your current branch is left untouched).
> > > 
> > > I must say this is a feature that would actually be nice to have...
> > 
> > To compare with the old one?  Use reflogs:
> > 
> > 	git filter-branch --some-option master
> > 	git diff master@{1}..master
> 
> To have, for example, a branch tracking an upstream (svn or whatever)
> repository and have a branch based on it, only differing in the fact that
> some directories get removed.