git-filter-branch

git-filter-branch

[Mike Hommey]

Hi,

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]

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.

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 ?

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.

Cheers,

Mike

Re: git-filter-branch

[Johannes Schindelin]

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.

Ciao,
Dscho

Re: git-filter-branch

[Mike Hommey]

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

Mike

Re: git-filter-branch

[Johannes Schindelin]

Hi,

On Thu, 9 Aug 2007, Mike Hommey wrote:

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

To compare with the old one?  Use reflogs:

	git filter-branch --some-option master
	git diff master@{1}..master

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

IIRC the "map" function will handle that.

Ciao,
Dscho

Re: git-filter-branch

[Mike Hommey]

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.

To be more specific, I'm tracking webkit's svn repository, and want to
have a branch which would be a base for making source tarballs for
debian, excluding a lot of cruft (such as LayoutTests which are *huge*,
or the website that also lives in the same svn trunk).

As files are added frequently in these directories, rebase or merge would
not be enough, and I'd like to be able to do this with a bare repository,
which rebase and merge don't allow me to...

So if you have a better idea than git-filter-branch for that, I'm open to
suggestions ;)

Cheers,

Mike

Re: git-filter-branch

[Johannes Schindelin]

Hi,

On Thu, 9 Aug 2007, Mike Hommey wrote:

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

You can always achieve the same effect by

	$ git branch new-branch master
	$ git filter-branch <options> master

Anyway, I'm off for a few days.

Ciao,
Dscho