{"thread":{"id":"9453","subject":"git-filter-branch","startedAt":"2007-08-09T06:34:53Z","lastAt":"2007-08-09T09:38:09Z","messageCount":6,"participants":["Mike Hommey","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50292","messageId":"20070809063453.GA12602@glandium.org","threadId":"9453","inReplyTo":null,"subject":"git-filter-branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-09T06:34:53Z","receivedAt":"2007-08-09T06:34:53Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nWhat is supposed to be the usage() of git-fetch-branch ?\n\ngit-filter-branch itself says:\ngit-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]\n\nwhile the documentation doesn't explicitely talk about DESTBRANCH,\nexpect in the form of an hypothetical /newbranch/, that you obviously\ndon't give to the command line.\n\nAnd whereas git-filter-branch itself says there is such an argument,\nit actually doesn't take it, and doesn't seem to be hardwired to create\na new branch instead of overwriting the current one.\n\nSo what is git-filter-branch supposed to be doing ?\n\nAs a side note, if it ever happens that git-filter-branch can create a\nnew branch, it might be nice to have each commit on the branch to have\nthe original commit as parent, as well as its branch parent, so that\nthey are seen as merges.\n\nCheers,\n\nMike\n"},{"id":"50303","messageId":"Pine.LNX.4.64.0708090954550.21857@racer.site","threadId":"9453","inReplyTo":"20070809063453.GA12602@glandium.org","subject":"Re: git-filter-branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-09T08:58:27Z","receivedAt":"2007-08-09T08:58:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Aug 2007, Mike Hommey wrote:\n\n> What is supposed to be the usage() of git-fetch-branch ?\n> \n> git-filter-branch itself says:\n> git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]\n\nThis is an unfortunate left-over. The syntax described in the \ndocumentation should be right.\n\n> while the documentation doesn't explicitely talk about DESTBRANCH,\n> expect in the form of an hypothetical /newbranch/, that you obviously\n> don't give to the command line.\n\nHmm. I don't have time to look into this now, but the syntax is this:\n\n\tgit filter-branch [] [--] []\n\nThose refs that you give in the are rewritten. AFAIR the \nold values of the refs (if different) are written to refs/original/*.\n\n> And whereas git-filter-branch itself says there is such an argument,\n> it actually doesn't take it, and doesn't seem to be hardwired to create\n> a new branch instead of overwriting the current one.\n> \n> So what is git-filter-branch supposed to be doing ?\n\nTo rewrite refs.\n\n> As a side note, if it ever happens that git-filter-branch can create a\n> new branch, it might be nice to have each commit on the branch to have\n> the original commit as parent, as well as its branch parent, so that\n> they are seen as merges.\n\nNo, this will not happen. Filter-branch is meant to clean up branches, so \nit will rewrite the commits. However, you might be able to hack something \nin a parent filter.\n\nCiao,\nDscho\n"},{"id":"50307","messageId":"20070809091550.GB20321@glandium.org","threadId":"9453","inReplyTo":"Pine.LNX.4.64.0708090954550.21857@racer.site","subject":"Re: git-filter-branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-09T09:15:50Z","receivedAt":"2007-08-09T09:15:50Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Aug 09, 2007 at 09:58:27AM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 9 Aug 2007, Mike Hommey wrote:\n> \n> > What is supposed to be the usage() of git-fetch-branch ?\n> > \n> > git-filter-branch itself says:\n> > git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]\n> \n> This is an unfortunate left-over. The syntax described in the \n> documentation should be right.\n> \n> > while the documentation doesn't explicitely talk about DESTBRANCH,\n> > expect in the form of an hypothetical /newbranch/, that you obviously\n> > don't give to the command line.\n> \n> Hmm. I don't have time to look into this now, but the syntax is this:\n> \n> \tgit filter-branch [] [--] []\n> \n> Those refs that you give in the are rewritten. AFAIR the \n> old values of the refs (if different) are written to refs/original/*.\n\nIn the description in the manpage:\n Lets you rewrite git revision history by creating a new branch from\n your current branch, applying custom filters on each revision.\n (...)\n The command takes the new branch name as a mandatory argument and the\n filters as optional arguments\n\nAnd in example:\n Now, you will get the rewritten history saved in the branch newbranch\n (your current branch is left untouched).\n\nI must say this is a feature that would actually be nice to have...\n\n> > And whereas git-filter-branch itself says there is such an argument,\n> > it actually doesn't take it, and doesn't seem to be hardwired to create\n> > a new branch instead of overwriting the current one.\n> > \n> > So what is git-filter-branch supposed to be doing ?\n> \n> To rewrite refs.\n> \n> > As a side note, if it ever happens that git-filter-branch can create a\n> > new branch, it might be nice to have each commit on the branch to have\n> > the original commit as parent, as well as its branch parent, so that\n> > they are seen as merges.\n> \n> No, this will not happen. Filter-branch is meant to clean up branches, so \n> it will rewrite the commits. However, you might be able to hack something \n> in a parent filter.\n\nThat would need the commit id for the original commit being treated at the\ntime, which I don't think is available in parent filters...\n\nMike\n"},{"id":"50308","messageId":"Pine.LNX.4.64.0708091018340.21857@racer.site","threadId":"9453","inReplyTo":"20070809091550.GB20321@glandium.org","subject":"Re: git-filter-branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-09T09:19:20Z","receivedAt":"2007-08-09T09:19:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Aug 2007, Mike Hommey wrote:\n\n> On Thu, Aug 09, 2007 at 09:58:27AM +0100, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Thu, 9 Aug 2007, Mike Hommey wrote:\n> > \n> > > What is supposed to be the usage() of git-fetch-branch ?\n> > > \n> > > git-filter-branch itself says:\n> > > git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]\n> > \n> > This is an unfortunate left-over. The syntax described in the \n> > documentation should be right.\n> > \n> > > while the documentation doesn't explicitely talk about DESTBRANCH,\n> > > expect in the form of an hypothetical /newbranch/, that you obviously\n> > > don't give to the command line.\n> > \n> > Hmm. I don't have time to look into this now, but the syntax is this:\n> > \n> > \tgit filter-branch [] [--] []\n> > \n> > Those refs that you give in the are rewritten. AFAIR the \n> > old values of the refs (if different) are written to refs/original/*.\n> \n> In the description in the manpage:\n> Lets you rewrite git revision history by creating a new branch from\n> your current branch, applying custom filters on each revision.\n> (...)\n> The command takes the new branch name as a mandatory argument and the\n> filters as optional arguments\n> \n> And in example:\n> Now, you will get the rewritten history saved in the branch newbranch\n> (your current branch is left untouched).\n> \n> I must say this is a feature that would actually be nice to have...\n\nTo compare with the old one? Use reflogs:\n\n\tgit filter-branch --some-option master\n\tgit diff master@{1}..master\n\n> > > And whereas git-filter-branch itself says there is such an argument,\n> > > it actually doesn't take it, and doesn't seem to be hardwired to create\n> > > a new branch instead of overwriting the current one.\n> > > \n> > > So what is git-filter-branch supposed to be doing ?\n> > \n> > To rewrite refs.\n> > \n> > > As a side note, if it ever happens that git-filter-branch can create a\n> > > new branch, it might be nice to have each commit on the branch to have\n> > > the original commit as parent, as well as its branch parent, so that\n> > > they are seen as merges.\n> > \n> > No, this will not happen. Filter-branch is meant to clean up branches, so \n> > it will rewrite the commits. However, you might be able to hack something \n> > in a parent filter.\n> \n> That would need the commit id for the original commit being treated at the\n> time, which I don't think is available in parent filters...\n\nIIRC the \"map\" function will handle that.\n\nCiao,\nDscho\n"},{"id":"50309","messageId":"20070809093051.GA21458@glandium.org","threadId":"9453","inReplyTo":"Pine.LNX.4.64.0708091018340.21857@racer.site","subject":"Re: git-filter-branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-08-09T09:30:51Z","receivedAt":"2007-08-09T09:30:51Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Aug 09, 2007 at 10:19:20AM +0100, Johannes Schindelin wrote:\n> > In the description in the manpage:\n> > Lets you rewrite git revision history by creating a new branch from\n> > your current branch, applying custom filters on each revision.\n> > (...)\n> > The command takes the new branch name as a mandatory argument and the\n> > filters as optional arguments\n> > \n> > And in example:\n> > Now, you will get the rewritten history saved in the branch newbranch\n> > (your current branch is left untouched).\n> > \n> > I must say this is a feature that would actually be nice to have...\n> \n> To compare with the old one? Use reflogs:\n> \n> \tgit filter-branch --some-option master\n> \tgit diff master@{1}..master\n\nTo have, for example, a branch tracking an upstream (svn or whatever)\nrepository and have a branch based on it, only differing in the fact that\nsome directories get removed.\n\nTo be more specific, I'm tracking webkit's svn repository, and want to\nhave a branch which would be a base for making source tarballs for\ndebian, excluding a lot of cruft (such as LayoutTests which are *huge*,\nor the website that also lives in the same svn trunk).\n\nAs files are added frequently in these directories, rebase or merge would\nnot be enough, and I'd like to be able to do this with a bare repository,\nwhich rebase and merge don't allow me to...\n\nSo if you have a better idea than git-filter-branch for that, I'm open to\nsuggestions ;)\n\nCheers,\n\nMike\n"},{"id":"50310","messageId":"Pine.LNX.4.64.0708091037220.21857@racer.site","threadId":"9453","inReplyTo":"20070809093051.GA21458@glandium.org","subject":"Re: git-filter-branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-09T09:38:09Z","receivedAt":"2007-08-09T09:38:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Aug 2007, Mike Hommey wrote:\n\n> On Thu, Aug 09, 2007 at 10:19:20AM +0100, Johannes Schindelin wrote:\n> > > In the description in the manpage:\n> > > Lets you rewrite git revision history by creating a new branch from\n> > > your current branch, applying custom filters on each revision.\n> > > (...)\n> > > The command takes the new branch name as a mandatory argument and the\n> > > filters as optional arguments\n> > > \n> > > And in example:\n> > > Now, you will get the rewritten history saved in the branch newbranch\n> > > (your current branch is left untouched).\n> > > \n> > > I must say this is a feature that would actually be nice to have...\n> > \n> > To compare with the old one? Use reflogs:\n> > \n> > \tgit filter-branch --some-option master\n> > \tgit diff master@{1}..master\n> \n> To have, for example, a branch tracking an upstream (svn or whatever)\n> repository and have a branch based on it, only differing in the fact that\n> some directories get removed.\n\nYou can always achieve the same effect by\n\n\t$ git branch new-branch master\n\t$ git filter-branch master\n\nAnyway, I'm off for a few days.\n\nCiao,\nDscho\n"}]}