{"thread":{"id":"43305","subject":"Merging five months of Linux kernel history","startedAt":"2006-10-29T19:32:28Z","lastAt":"2006-10-30T08:05:19Z","messageCount":4,"participants":["Jan-Benedict Glaw","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294286","messageId":"20061029193228.GR26271@lug-owl.de","threadId":"43305","inReplyTo":null,"subject":"Merging five months of Linux kernel history","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-10-29T19:32:28Z","receivedAt":"2006-10-29T19:32:28Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"Hi!\n\nDue to a move to a new flat and other reasons, I wasn't able to\ndo daily merges from Linus's tree into our vax-linux tree.\nMy time situation has improved and I want to merge all the new\nand shiny stuff, but it seems a straight \"git pull\" isn't the\nbest way to do that.\n\nWhat I'd actually love to do is to go through all commits since the\nlast merge and pull/accept/cherry-pick then one by one. That way I'll\nlearn about new stuff. I'll specifically see generic changes that\nimply arch-specific stuff, things I'll need to implement later on.\n\nIs there any sane way to cluse such a large gap? I don't mind looking\nthrough tenthousands of commits, as long as I get a chance to spot\n\"important\" ones.\n\nThanks, JBG\n\n-- \n Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481\nSignature of: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html\nthe second :\n"},{"id":"294474","messageId":"7vhcxm274i.fsf@assigned-by-dhcp.cox.net","threadId":"43305","inReplyTo":"20061029193228.GR26271@lug-owl.de","subject":"Re: Merging five months of Linux kernel history","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-29T20:34:53Z","receivedAt":"2006-10-29T20:34:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan-Benedict Glaw writes:\n\n> Hi!\n>\n> Due to a move to a new flat and other reasons, I wasn't able to\n> do daily merges from Linus's tree into our vax-linux tree.\n> My time situation has improved and I want to merge all the new\n> and shiny stuff, but it seems a straight \"git pull\" isn't the\n> best way to do that.\n>\n> What I'd actually love to do is to go through all commits since the\n> last merge and pull/accept/cherry-pick then one by one. That way I'll\n> learn about new stuff. I'll specifically see generic changes that\n> imply arch-specific stuff, things I'll need to implement later on.\n>\n> Is there any sane way to cluse such a large gap? I don't mind looking\n> through tenthousands of commits, as long as I get a chance to spot\n> \"important\" ones.\n\nI think the best way is:\n\n\tgit pull\n git log ORIG_HEAD..\n\nThe latter would give your ten thousands of commits to inspect.\n\nIf the pull results in a conflict, then\n\n\tgit pull\n\tgit log --merge\n\n\t... fix conflicts ...\n\tgit commit\n git log ORIG_HEAD..\n\nSince ORIG_HEAD is transient, and you probably would want to\nrevisit the list of these ten thousands of commits later, it\nmight make sense to do\n\n\tgit tag WHERE_WE_WERE\n\nbefore \"git pull\" in either case.\n\n"},{"id":"294547","messageId":"20061030075002.GT26271@lug-owl.de","threadId":"43305","inReplyTo":"7vhcxm274i.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merging five months of Linux kernel history","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-10-30T07:50:02Z","receivedAt":"2006-10-30T07:50:02Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-10-29 12:34:53 -0800, Junio C Hamano wrote:\n> Jan-Benedict Glaw writes:\n> > Due to a move to a new flat and other reasons, I wasn't able to\n> > do daily merges from Linus's tree into our vax-linux tree.\n> > My time situation has improved and I want to merge all the new\n> > and shiny stuff, but it seems a straight \"git pull\" isn't the\n> > best way to do that.\n> >\n> > What I'd actually love to do is to go through all commits since the\n> > last merge and pull/accept/cherry-pick then one by one. That way I'll\n> > learn about new stuff. I'll specifically see generic changes that\n> > imply arch-specific stuff, things I'll need to implement later on.\n> >\n> > Is there any sane way to cluse such a large gap? I don't mind looking\n> > through tenthousands of commits, as long as I get a chance to spot\n> > \"important\" ones.\n> \n> I think the best way is:\n> \n> \tgit pull\n> git log ORIG_HEAD..\n> \n> The latter would give your ten thousands of commits to inspect.\n> \n> If the pull results in a conflict, then\n> \n> \tgit pull\n> \tgit log --merge\n> \n> \t... fix conflicts ...\n> \tgit commit\n> git log ORIG_HEAD..\n\nThat's the point--I don't really expect any conflicts, or only a very\nlittle number of them. Basically, only the Makefiles and the Kconfig\nfiles do have a chance to conflict. It's no more than a new arch/\ndirectory and some drivers.\n\nThe hard part will be to figure out all the needed changes in arch\ncode, like the IRQ handling rework etc :)\n\nMfG, JBG\n\n-- \n Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481\nSignature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.\nthe second : Langsam möchte ich mal wieder weiterträumen können.\n"},{"id":"296311","messageId":"7vk62ixm80.fsf@assigned-by-dhcp.cox.net","threadId":"43305","inReplyTo":"20061030075002.GT26271@lug-owl.de","subject":"Re: Merging five months of Linux kernel history","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-30T08:05:19Z","receivedAt":"2006-10-30T08:05:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan-Benedict Glaw writes:\n\n>> git log ORIG_HEAD..\n>\n> That's the point--I don't really expect any conflicts, or only a very\n> little number of them. Basically, only the Makefiles and the Kconfig\n> files do have a chance to conflict. It's no more than a new arch/\n> directory and some drivers.\n>\n> The hard part will be to figure out all the needed changes in arch\n> code, like the IRQ handling rework etc :)\n\nSince you are maintaining your own arch/ and the other in-tree\narchitectures progressed as common core code did, you would want\nto make matching changes to your arch to adjust to the core\nchanges.\n\n[a big warning in red capital letters: I do not hack kernel]\n\nI suspect you would want to see what _other_ architecture did to\nadjust to the changes in the common core code that happened in\nthe meantime. How about...\n\n$ git log ORIG_HEAD.. -- arch/$somearch include/asm-$somearch\n\nwhere $somearch is something that has difference from the\nmainstream that is similar to vax, to figure out what other\narchitectures needed to adjust, perhaps?\n"}]}