{"thread":{"id":"8877","subject":"Embedded Linux development with GIT","startedAt":"2007-07-05T05:50:34Z","lastAt":"2007-07-05T12:00:26Z","messageCount":5,"participants":["Sean Kelley","Dan Chokola","Alex Riesen","Johannes Sixt","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46530","messageId":"a2e879e50707042250w22fe570cp4dda316e6b0f4cea@mail.gmail.com","threadId":"8877","inReplyTo":null,"subject":"Embedded Linux development with GIT","fromName":"Sean Kelley","fromEmail":"svk.sweng@gmail.com","sentAt":"2007-07-05T05:50:34Z","receivedAt":"2007-07-05T05:50:34Z","isPatch":false,"sender":{"key":"svk.sweng@gmail.com","avatar":null},"body":"Hi,\n\nI have a situation where we have a local GIT repository that is based\non v2.6.17.  We initially added the source tarball to an empty\nrepository and then started applying changes to it.  Looking back,\nthat might not have been the best idea 400 commits later.\n\nMy goal is to eventually bring our repository closer to mainline\nrevisions so as to make it easier to actually contribute back to the\ncommunity.  So how can I fix my repository so as to give it visibility\nto Linus' kernel?\n\nHere is my initial thoughts:\n\n1) Clone kernel.org kernel and it is Master\n2) Create a local Head based on 2.6.17 and call it Local\n3) Pull my existing heavily patched repository into the Local branch and merge\n\nIs it possible then to see our 400 odd commits then in the Local\nbranch on top of 2.6.17 so that we can see not only our history but\nalso the history that came before?  Then as Master advances we can see\nabout backporting and bringing our code close enough to mainline\nkernel to actually be able to contribute back to the community and\nsubmit patches.  Is this realistic approach.  I am unsure of the GIT\ncommands that I need to do this?\n\nThanks,\n\nSean\n"},{"id":"46531","messageId":"61e816970707042306n65e90e02lef1ce648be4225b@mail.gmail.com","threadId":"8877","inReplyTo":"a2e879e50707042250w22fe570cp4dda316e6b0f4cea@mail.gmail.com","subject":"Re: Embedded Linux development with GIT","fromName":"Dan Chokola","fromEmail":"dan@chokola.com","sentAt":"2007-07-05T06:06:13Z","receivedAt":"2007-07-05T06:06:13Z","isPatch":false,"sender":{"key":"dan@chokola.com","avatar":null},"body":"On 7/5/07, Sean Kelley <svk.sweng@gmail.com> wrote:\n> Hi,\n>\n> I have a situation where we have a local GIT repository that is based\n> on v2.6.17.  We initially added the source tarball to an empty\n> repository and then started applying changes to it.  Looking back,\n> that might not have been the best idea 400 commits later.\n>\n> My goal is to eventually bring our repository closer to mainline\n> revisions so as to make it easier to actually contribute back to the\n> community.  So how can I fix my repository so as to give it visibility\n> to Linus' kernel?\n>\n> Here is my initial thoughts:\n>\n> 1) Clone kernel.org kernel and it is Master\n> 2) Create a local Head based on 2.6.17 and call it Local\n> 3) Pull my existing heavily patched repository into the Local branch and merge\n>\n> Is it possible then to see our 400 odd commits then in the Local\n> branch on top of 2.6.17 so that we can see not only our history but\n> also the history that came before?  Then as Master advances we can see\n> about backporting and bringing our code close enough to mainline\n> kernel to actually be able to contribute back to the community and\n> submit patches.  Is this realistic approach.  I am unsure of the GIT\n> commands that I need to do this?\n>\n> Thanks,\n>\n> Sean\n\nIf I understand correctly, what you might want to do is keep your\ncurrent master branch, pull in the mainline kernel to a separate\nbranch, and rebase your master on the mainline branch.\n\ngit checkout master\ngit rebase mainline\nwill find the last common commit between two branches, then plop all\nthe mainline commits on top, then proceed to merge in your changes on\nthe master branch, one-by-one, stopping if there are any conflicts and\nallowing you to resolve as they happen. Then your 400 commits will be\non top and you can rebase whenever and still see them on top.\n\n-Dan \"Puzzles\" Chokola\n"},{"id":"46532","messageId":"81b0412b0707042353o437a88faycbead87f63998913@mail.gmail.com","threadId":"8877","inReplyTo":"a2e879e50707042250w22fe570cp4dda316e6b0f4cea@mail.gmail.com","subject":"Re: Embedded Linux development with GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-07-05T06:53:37Z","receivedAt":"2007-07-05T06:53:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 7/5/07, Sean Kelley <svk.sweng@gmail.com> wrote:\n> 1) Clone kernel.org kernel and it is Master\n> 2) Create a local Head based on 2.6.17 and call it Local\n> 3) Pull my existing heavily patched repository into the Local branch and merge\n\nBetter:\n\n  $ (cd $OLDREPO && git format-patch --stdout -k first..) | git am -k\n\nor, if it is in the same repo, assuming it starts with sha1 \"old-beginning\"\n\n  $ git format-patch --stdout -k old-beginning.. | git am -k\n\nMerging of unrelated histories is slow (but works).\n\n> Is it possible then to see our 400 odd commits then in the Local\n> branch on top of 2.6.17 so that we can see not only our history but\n> also the history that came before?  Then as Master advances we can see\n> about backporting and bringing our code close enough to mainline\n> kernel to actually be able to contribute back to the community and\n> submit patches.  Is this realistic approach.\n\nYes. Look at how OLPC (www.laptop.org) does this with their kernel.\n\n>  I am unsure of the GIT\n> commands that I need to do this?\n\naside from the already mentioned git format-patch and git am:\ngit apply, git log, git show, gitk, and come to think of it - all of the\nrest too, except maybe for importing programs.\n"},{"id":"46533","messageId":"468C996B.7FEFEB29@eudaptics.com","threadId":"8877","inReplyTo":"a2e879e50707042250w22fe570cp4dda316e6b0f4cea@mail.gmail.com","subject":"Re: Embedded Linux development with GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-07-05T07:10:35Z","receivedAt":"2007-07-05T07:10:35Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Sean Kelley wrote:\n> \n> Hi,\n> \n> I have a situation where we have a local GIT repository that is based\n> on v2.6.17.  We initially added the source tarball to an empty\n> repository and then started applying changes to it.  Looking back,\n> that might not have been the best idea 400 commits later.\n> \n> My goal is to eventually bring our repository closer to mainline\n> revisions so as to make it easier to actually contribute back to the\n> community.  So how can I fix my repository so as to give it visibility\n> to Linus' kernel?\n> \n> Here is my initial thoughts:\n> \n> 1) Clone kernel.org kernel and it is Master\n> 2) Create a local Head based on 2.6.17 and call it Local\n> 3) Pull my existing heavily patched repository into the Local branch and merge\n> \n> Is it possible then to see our 400 odd commits then in the Local\n> branch on top of 2.6.17 so that we can see not only our history but\n> also the history that came before?  Then as Master advances we can see\n> about backporting and bringing our code close enough to mainline\n> kernel to actually be able to contribute back to the community and\n> submit patches.  Is this realistic approach.  I am unsure of the GIT\n> commands that I need to do this?\n\nThat is possible using a graft:\n\n  $ echo \"$x $(git rev-parse v2.6.17^0)\" >> .git/info/grafts\n\nwhere $x is the SHA1 of the first commit you made on top of the imported\ntarball. This way you have spliced your history with Linus's history.\n(This is a strictly _local_ matter! Every clone of your history must\nrepeat the game!)\n\nNow, Linus will not be able to pull from your faked history because he\ndoesn't know about the graft. In order to fix that, you can run\ngit-filter-branch from current git's master branch to rewrite your\nhistory:\n\n  $ git filter-branch new-master v2.6.17..master\n\nRead the man page of git-filter-branch, and understand the implications\nbefore you publish the result.\n\n-- Hannes\n"},{"id":"46543","messageId":"Pine.LNX.4.64.0707051253130.9789@racer.site","threadId":"8877","inReplyTo":"468C996B.7FEFEB29@eudaptics.com","subject":"Re: Embedded Linux development with GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-05T12:00:26Z","receivedAt":"2007-07-05T12:00:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 5 Jul 2007, Johannes Sixt wrote:\n\n> Sean Kelley wrote:\n> > \n> > I have a situation where we have a local GIT repository that is based\n> > on v2.6.17.  We initially added the source tarball to an empty\n> > repository and then started applying changes to it.  Looking back,\n> > that might not have been the best idea 400 commits later.\n> \n> That is possible using a graft:\n> \n>   $ echo \"$x $(git rev-parse v2.6.17^0)\" >> .git/info/grafts\n> \n> where $x is the SHA1 of the first commit you made on top of the imported\n> tarball.\n\nYes, this is also how I would do it.\n\n> This way you have spliced your history with Linus's history. (This is a \n> strictly _local_ matter! Every clone of your history must repeat the \n> game!)\n\nNow, here I disagree slightly.  If you merge just once, subsequent merges \nwill be possible even without that graft.\n\nSo if you merge with some newer Linux version, all your cloners get the \nbenefit.\n\n> Now, Linus will not be able to pull from your faked history because he\n> doesn't know about the graft.\n\nExcept if you merge with a more recent version of Linux.\n\nHowever, I doubt that such a distant (in terms of time!) merge would \nappeal to Linus.  I guess you have to rebase on top of Linus' version \n_anyway_.\n\n> In order to fix that, you can run git-filter-branch from current git's \n> master branch to rewrite your history:\n> \n>   $ git filter-branch new-master v2.6.17..master\n> \n> Read the man page of git-filter-branch, and understand the implications\n> before you publish the result.\n\nThis is a way to fix your history, yes.  Note that filter-branch is not \nyet in an official release of Git, and so you either have to wait for \n1.5.3, or you get filter-branch from git.git's \"next\" branch (just picking \nthis one script should work fine, if you have at least 1.5.1 installed).\n\nNote that this rewrites the history, so all the disadvantages of \nrebasing with pulling apply here, too.\n\nBut as stated above, I think you have to rebase eventually anyway, if you \ngo for inclusion in Linus' tree.  In that case, the filter-branch is \nunnecessary.\n\nCiao,\nDscho\n"}]}