Hi,
On Thu, 9 Aug 2007, Mike Hommey wrote:
> On Thu, Aug 09, 2007 at 09:58:27AM +0100, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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
-
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
