{"thread":{"id":"11050","subject":"Cover grafting in the Git User's Manual","startedAt":"2007-11-28T18:23:01Z","lastAt":"2007-11-29T18:10:02Z","messageCount":4,"participants":["Markus Armbruster","Peter Baumann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61260","messageId":"87ejeateka.fsf@pike.pond.sub.org","threadId":"11050","inReplyTo":null,"subject":"Cover grafting in the Git User's Manual","fromName":"Markus Armbruster","fromEmail":"armbru@redhat.com","sentAt":"2007-11-28T18:23:01Z","receivedAt":"2007-11-28T18:23:01Z","isPatch":false,"sender":{"key":"armbru@redhat.com","avatar":null},"body":"The only mention of grafting in the manual is in the glossary:\n\n    Grafts enables two otherwise different lines of development to\n    be joined together by recording fake ancestry information for\n    commits. This way you can make git pretend the set of parents\n    a commit has is different from what was recorded when the\n    commit was created. Configured via the .git/info/grafts file.\n\nI believe it would be useful to cover this better, perhaps in chapter\n5. Rewriting history and maintaining patch series.  It certainly would\nhave saved me a few hours of digging.  I already understood enough of\ngit to *know* that what I wanted must be possible (supply missing\nparents of merges in a repository imported with parsecvs), but I\ndidn't know the magic keyword was graft.  I managed to figure it out\nfrom the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.\n\nI'm neither writer nor git expert, but here's my try anyway:\n\nRewriting ancestry with grafts\n\nGrafts enables two otherwise different lines of development to be\njoined together by recording fake ancestry information for commits.\nThis way you can make git pretend the set of parents a commit has is\ndifferent from what was recorded when the commit was created.\n\nWhy would you want to do that?  Say, you imported a repository from an\nSCM that doesn't record merges properly, e.g. CVS.  Grafts let you add\nthe missing parents to the merge commits.  Or you switched your\nproject to git by populating a new repository with current sources,\nand later decide you want more history.  Committing old versions is\neasy enough, but you also need to graft a parent to your original root\ncommit.\n\nGraft points are configured via the .git/info/grafts file.  It has one\nrecord per line describing a commit and its fake parents by listing\nobject names separated by a space and terminated by a newline.\n\n    <commit sha1> <parent sha1> [<parent sha1>]*\n\nA graft point does not actually change its commit.  Nothing can.  What\ncan be done is rewriting the commit and its descendants.\ngit-filter-branch does that:\n\n    $ cat .git/info/grafts\n    db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n    git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n\nThis rewrites history between head and the graft-point to include the\ngrafted parents.\n"},{"id":"61264","messageId":"20071128184228.GB4461@xp.machine.xx","threadId":"11050","inReplyTo":"87ejeateka.fsf@pike.pond.sub.org","subject":"Re: Cover grafting in the Git User's Manual","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-11-28T18:42:28Z","receivedAt":"2007-11-28T18:42:28Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Nov 28, 2007 at 07:23:01PM +0100, Markus Armbruster wrote:\n> The only mention of grafting in the manual is in the glossary:\n> \n>     Grafts enables two otherwise different lines of development to\n>     be joined together by recording fake ancestry information for\n>     commits. This way you can make git pretend the set of parents\n>     a commit has is different from what was recorded when the\n>     commit was created. Configured via the .git/info/grafts file.\n> \n> I believe it would be useful to cover this better, perhaps in chapter\n> 5. Rewriting history and maintaining patch series.  It certainly would\n> have saved me a few hours of digging.  I already understood enough of\n> git to *know* that what I wanted must be possible (supply missing\n> parents of merges in a repository imported with parsecvs), but I\n> didn't know the magic keyword was graft.  I managed to figure it out\n> >from the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.\n> \n> I'm neither writer nor git expert, but here's my try anyway:\n> \n> Rewriting ancestry with grafts\n> \n> Grafts enables two otherwise different lines of development to be\n> joined together by recording fake ancestry information for commits.\n> This way you can make git pretend the set of parents a commit has is\n> different from what was recorded when the commit was created.\n> \n> Why would you want to do that?  Say, you imported a repository from an\n> SCM that doesn't record merges properly, e.g. CVS.  Grafts let you add\n> the missing parents to the merge commits.  Or you switched your\n> project to git by populating a new repository with current sources,\n> and later decide you want more history.  Committing old versions is\n> easy enough, but you also need to graft a parent to your original root\n> commit.\n> \n> Graft points are configured via the .git/info/grafts file.  It has one\n> record per line describing a commit and its fake parents by listing\n> object names separated by a space and terminated by a newline.\n> \n>     <commit sha1> <parent sha1> [<parent sha1>]*\n> \n> A graft point does not actually change its commit.  Nothing can.  What\n> can be done is rewriting the commit and its descendants.\n> git-filter-branch does that:\n> \n>     $ cat .git/info/grafts\n>     db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n>     git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n> \n> This rewrites history between head and the graft-point to include the\n> grafted parents.\n\nDid I overlook something or isn't\n\n     git-filter-branch HEAD ^db5a561750ae87615719ae409d1f50c9dfc3fa71\n\nwhat you are looking for? Only db5a56 could get rewritten and obviously\nall the commits having it as a parent.\n\n-Peter\n"},{"id":"61394","messageId":"87bq9drxwf.fsf@pike.pond.sub.org","threadId":"11050","inReplyTo":"20071128184228.GB4461@xp.machine.xx","subject":"Re: Cover grafting in the Git User's Manual","fromName":"Markus Armbruster","fromEmail":"armbru@redhat.com","sentAt":"2007-11-29T13:20:32Z","receivedAt":"2007-11-29T13:20:32Z","isPatch":false,"sender":{"key":"armbru@redhat.com","avatar":null},"body":"Peter Baumann <waste.manager@gmx.de> writes:\n\n> On Wed, Nov 28, 2007 at 07:23:01PM +0100, Markus Armbruster wrote:\n>> The only mention of grafting in the manual is in the glossary:\n>> \n>>     Grafts enables two otherwise different lines of development to\n>>     be joined together by recording fake ancestry information for\n>>     commits. This way you can make git pretend the set of parents\n>>     a commit has is different from what was recorded when the\n>>     commit was created. Configured via the .git/info/grafts file.\n>> \n>> I believe it would be useful to cover this better, perhaps in chapter\n>> 5. Rewriting history and maintaining patch series.  It certainly would\n>> have saved me a few hours of digging.  I already understood enough of\n>> git to *know* that what I wanted must be possible (supply missing\n>> parents of merges in a repository imported with parsecvs), but I\n>> didn't know the magic keyword was graft.  I managed to figure it out\n>> >from the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.\n>> \n>> I'm neither writer nor git expert, but here's my try anyway:\n>> \n>> Rewriting ancestry with grafts\n>> \n>> Grafts enables two otherwise different lines of development to be\n>> joined together by recording fake ancestry information for commits.\n>> This way you can make git pretend the set of parents a commit has is\n>> different from what was recorded when the commit was created.\n>> \n>> Why would you want to do that?  Say, you imported a repository from an\n>> SCM that doesn't record merges properly, e.g. CVS.  Grafts let you add\n>> the missing parents to the merge commits.  Or you switched your\n>> project to git by populating a new repository with current sources,\n>> and later decide you want more history.  Committing old versions is\n>> easy enough, but you also need to graft a parent to your original root\n>> commit.\n>> \n>> Graft points are configured via the .git/info/grafts file.  It has one\n>> record per line describing a commit and its fake parents by listing\n>> object names separated by a space and terminated by a newline.\n>> \n>>     <commit sha1> <parent sha1> [<parent sha1>]*\n>> \n>> A graft point does not actually change its commit.  Nothing can.  What\n>> can be done is rewriting the commit and its descendants.\n>> git-filter-branch does that:\n>> \n>>     $ cat .git/info/grafts\n>>     db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n>>     git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n>> \n>> This rewrites history between head and the graft-point to include the\n>> grafted parents.\n>\n> Did I overlook something or isn't\n>\n>      git-filter-branch HEAD ^db5a561750ae87615719ae409d1f50c9dfc3fa71\n>\n> what you are looking for? Only db5a56 could get rewritten and obviously\n> all the commits having it as a parent.\n>\n> -Peter\n\nThat rewrites all commits reachable from HEAD that are not reachable\nfrom db5a56.  In particular, it doesn't rewrite db5a56, does it?\n"},{"id":"61413","messageId":"20071129181002.GA13114@xp.machine.xx","threadId":"11050","inReplyTo":"87bq9drxwf.fsf@pike.pond.sub.org","subject":"Re: Cover grafting in the Git User's Manual","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-11-29T18:10:02Z","receivedAt":"2007-11-29T18:10:02Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Thu, Nov 29, 2007 at 02:20:32PM +0100, Markus Armbruster wrote:\n> Peter Baumann <waste.manager@gmx.de> writes:\n> \n> > On Wed, Nov 28, 2007 at 07:23:01PM +0100, Markus Armbruster wrote:\n> >> The only mention of grafting in the manual is in the glossary:\n> >> \n> >>     Grafts enables two otherwise different lines of development to\n> >>     be joined together by recording fake ancestry information for\n> >>     commits. This way you can make git pretend the set of parents\n> >>     a commit has is different from what was recorded when the\n> >>     commit was created. Configured via the .git/info/grafts file.\n> >> \n> >> I believe it would be useful to cover this better, perhaps in chapter\n> >> 5. Rewriting history and maintaining patch series.  It certainly would\n> >> have saved me a few hours of digging.  I already understood enough of\n> >> git to *know* that what I wanted must be possible (supply missing\n> >> parents of merges in a repository imported with parsecvs), but I\n> >> didn't know the magic keyword was graft.  I managed to figure it out\n> >> >from the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.\n> >> \n> >> I'm neither writer nor git expert, but here's my try anyway:\n> >> \n> >> Rewriting ancestry with grafts\n> >> \n> >> Grafts enables two otherwise different lines of development to be\n> >> joined together by recording fake ancestry information for commits.\n> >> This way you can make git pretend the set of parents a commit has is\n> >> different from what was recorded when the commit was created.\n> >> \n> >> Why would you want to do that?  Say, you imported a repository from an\n> >> SCM that doesn't record merges properly, e.g. CVS.  Grafts let you add\n> >> the missing parents to the merge commits.  Or you switched your\n> >> project to git by populating a new repository with current sources,\n> >> and later decide you want more history.  Committing old versions is\n> >> easy enough, but you also need to graft a parent to your original root\n> >> commit.\n> >> \n> >> Graft points are configured via the .git/info/grafts file.  It has one\n> >> record per line describing a commit and its fake parents by listing\n> >> object names separated by a space and terminated by a newline.\n> >> \n> >>     <commit sha1> <parent sha1> [<parent sha1>]*\n> >> \n> >> A graft point does not actually change its commit.  Nothing can.  What\n> >> can be done is rewriting the commit and its descendants.\n> >> git-filter-branch does that:\n> >> \n> >>     $ cat .git/info/grafts\n> >>     db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n> >>     git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251\n> >> \n> >> This rewrites history between head and the graft-point to include the\n> >> grafted parents.\n> >\n> > Did I overlook something or isn't\n> >\n> >      git-filter-branch HEAD ^db5a561750ae87615719ae409d1f50c9dfc3fa71\n> >\n> > what you are looking for? Only db5a56 could get rewritten and obviously\n> > all the commits having it as a parent.\n> >\n> > -Peter\n> \n> That rewrites all commits reachable from HEAD that are not reachable\n> >from db5a56.  In particular, it doesn't rewrite db5a56, does it?\n\nUh. You are right. I *meant*\n\n\tgit filter-branch HEAD ^db5a561750ae87615719ae409d1f50c9dfc3fa71^\n\n\n-Peter\n"}]}