Re: git-filter-branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux