{"thread":{"id":"2817","subject":"branching and supporting a tagged kernel version","startedAt":"2005-12-12T21:31:08Z","lastAt":"2005-12-13T00:01:41Z","messageCount":4,"participants":["Don Zickus","Junio C Hamano","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13532","messageId":"68948ca0512121331x13bfb691t62224d02ced04a27@mail.gmail.com","threadId":"2817","inReplyTo":null,"subject":"branching and supporting a tagged kernel version","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-12T21:31:08Z","receivedAt":"2005-12-12T21:31:08Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"Hello,\n\nI was trying to see if I can use git for a particular way of\nsupporting a kernel and was hoping for some feedback if this approach\nwould work.\n\nBasically I wanted to branch off of 2.6.14 and support personal\npatches.  However over time I would like to be able to merge in\nhand-pick commits from upstream.\n\nSo my questions (for now) are:\n\n1) what is the easiest way to branch off on a tagged version (in this\ncase 2.6.14)?  I didn't quite understand what <starting point>\nreferred to in the git-branch docs.\n\n2) is there a way to get a list of commits from upstream that are not\nin my branch and then selectively apply them?  Yes, I understand the\npotential merge mess...\n\nThanks,\nDon\n"},{"id":"13534","messageId":"7virtueycd.fsf@assigned-by-dhcp.cox.net","threadId":"2817","inReplyTo":"68948ca0512121331x13bfb691t62224d02ced04a27@mail.gmail.com","subject":"Re: branching and supporting a tagged kernel version","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-12T22:37:22Z","receivedAt":"2005-12-12T22:37:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus <dzickus@gmail.com> writes:\n\n> So my questions (for now) are:\n>\n> 1) what is the easiest way to branch off on a tagged version (in this\n> case 2.6.14)?  I didn't quite understand what <starting point>\n> referred to in the git-branch docs.\n\nStarting point is badly worded, but essentially it means\n\"anything that names a particular commit\".  That's the commit\nyou want to base your branch off of.\n\nIn your case, you would run:\n\n------------\n$ git clone git://git.kernel.org/pub/.../torvalds/linux-2.6/ my2.6\n$ cd my2.6\n$ git checkout -b private v2.6.14\n------------\n\nto create and checkout a branch called \"private\" to house your\npersonal changes, based on v2.6.14.  Your working tree is based\non v2.6.14 and you are on the \"private\" branch immediately after\nthis operation, and you should see no diff from either of these\ncommands:\n\n------------\n$ git diff v2.6.14 <1>\n$ git diff private v2.6.14 <2>\n\n<1> compare your work tree with v2.6.14 tagged by Linus\n<2> compare \"private\" branch head with v2.6.14 tagged by Linus\n------------\n\nThen work as usual, the cycle is:\n\n------------\n$ edit\n$ git diff ;# to see how well you are doing\n$ compile\n$ test\n$ git diff HEAD ;# final review before committing\n$ git commit -a ;# commit all changes as you tested\n------------\n\n> 2) is there a way to get a list of commits from upstream that are not\n> in my branch and then selectively apply them?  Yes, I understand the\n> potential merge mess...\n\nI'll refrain from saying that it is not the usual way to work\nwith git, since you seem to know what you are doing.  So let's\nassume that you somehow do not ever want to merge from Linus\nhead into the \"private\" branch.\n\nAfter you have worked there:\n\n------------\n$ git fetch origin\n$ git cherry origin private\n------------\n\nwould show the list of commits since you forked from origin, \nwhich is Linus head --- when you run \"git clone\" to set up\n\"my2.6\" repository, it would have made .git/remotes/origin\nshorthand that has this line in it:\n\n------------\nURL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\nPull: master:origin\n------------\n\npick the ones you want, and apply them with:\n\n------------\n$ git cherry-pick 12233445....\n------------\n"},{"id":"13536","messageId":"68948ca0512121558s6e300103t95fcc0e9573604a7@mail.gmail.com","threadId":"2817","inReplyTo":"7virtueycd.fsf@assigned-by-dhcp.cox.net","subject":"Re: branching and supporting a tagged kernel version","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-12T23:58:38Z","receivedAt":"2005-12-12T23:58:38Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"Thanks for clearing things up.\n\n> I'll refrain from saying that it is not the usual way to work\n> with git, since you seem to know what you are doing.  So let's\n\nEither this or cvs. :)  Anyway my work involves releasing a platform\nto customers who don't want  to constantly upgrade their kernel.  And\ninstead of waiting for bugs to be filed, I was just trying to find a\nway to be pro-active and fix certain bugs _before_ our customers hit\nthem.\n\nCheers,\nDon\n"},{"id":"13537","messageId":"20051213000140.GZ22159@pasky.or.cz","threadId":"2817","inReplyTo":"68948ca0512121558s6e300103t95fcc0e9573604a7@mail.gmail.com","subject":"Re: branching and supporting a tagged kernel version","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-13T00:01:41Z","receivedAt":"2005-12-13T00:01:41Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Dec 13, 2005 at 12:58:38AM CET, I got a letter\nwhere Don Zickus <dzickus@gmail.com> said that...\n> Thanks for clearing things up.\n> \n> > I'll refrain from saying that it is not the usual way to work\n> > with git, since you seem to know what you are doing.  So let's\n> \n> Either this or cvs. :)  Anyway my work involves releasing a platform\n> to customers who don't want  to constantly upgrade their kernel.  And\n> instead of waiting for bugs to be filed, I was just trying to find a\n> way to be pro-active and fix certain bugs _before_ our customers hit\n> them.\n\nYou might also consider managing your patches in StGIT, which could give\nyou more comfort for managing them. StGIT provides quilt-like\nfunctionality on top of GIT, and it's easy to reorder, add, and remove\npatches, as well as submit them to the upstream and remove them\nautomatically when they get merged.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"}]}