{"thread":{"id":"3208","subject":"How to use git for Linux kernel development ?","startedAt":"2006-02-01T11:38:44Z","lastAt":"2006-02-01T21:43:45Z","messageCount":3,"participants":["Laurent Pinchart","J. Bruce Fields","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15384","messageId":"200602011238.44188.laurent.pinchart@tbox.biz","threadId":"3208","inReplyTo":null,"subject":"How to use git for Linux kernel development ?","fromName":"Laurent Pinchart","fromEmail":"laurent.pinchart@tbox.biz","sentAt":"2006-02-01T11:38:44Z","receivedAt":"2006-02-01T11:38:44Z","isPatch":false,"sender":{"key":"laurent.pinchart@tbox.biz","avatar":null},"body":"Hi everybody,\n\nmy company decided to port the Linux kernel to custom hardware. As we need a \nrepository for the sources, I thought I would give git a try. The man pages \nand tutorials are quite helpful to understand the git commands, but none of \nthe documentation I found has been able to answer my (not so simple) \nquestion : given my use cases, how do I use git ?\n\nHere are the use cases.\n\nI need to port the Linux kernel to custom hardware. This means fixing bugs in \nthe kernel, adding new features and new device drivers. Some of the \nmodifications I make (bug fixes) will be pushed upstream by myself, some \nothers by other developers (for instance I will apply patches found on \nsourceforge to support our non-UHCI/OHCI USB host controller, and I don't \nwant to push code for which I'm not the maintainer upstream), and some device \ndrivers will not be pushed at all.\n\nI will base my work on the Linux kernel 2.6.15, which is the most recent \nrelease that has the features I need (2.6.16-rc1 broke serial port support on \nFreescale PowerQuickII processors). I plan to stay up-to-date with the main \nkernel repository by either fixing the problems in future releases or waiting \nfor someone to fix them, depending on how much time I can spend on the \nproject.\n\nI have no idea how to layout my git repository to work on day-to-day \ndevelopment. I need to :\n\n- commit bug fixes, external patches and internal modifications to a branch \n(or possibly on separate branches depending on what I commit if needed). The \nwork will be based on Linux kernel 2.6.15 but I'd like to stay up-to-date \nwith the master repository as much as possible.\n- push bug fixes upstream by creating a patchset and submitting it by email.\n- pull changes from upstream and merge them in my various branches when the \nupstream versions become stable enough.\n- keep branches for all the versions shipped to the customers for bug fixes.\n\nI'm the only developer working on the Linux kernel in my company, but that \nmight change in a few months, so other developers will need to use git as \nwell.\n\nIs git able to accomodate my needs ? I've been trying to setup a git \nrepository with a few branches over the last two days, but I always had to \nthrow everything away and start back from zero. I haven't been able to figure \nout which branches I should create and how I should use them.\n\nThanks in advance for your help, and I hope I'm not asking too much. If really \nunable to use git, I'll go for SVN (or SourceSafe as that's what my company \nused until today, but I'd like to avoid it) even if I feel it will make \nkeeping up-to-date with upstream more difficult.\n\nLaurent Pinchart\n"},{"id":"15426","messageId":"20060201203842.GB5900@fieldses.org","threadId":"3208","inReplyTo":"200602011238.44188.laurent.pinchart@tbox.biz","subject":"Re: How to use git for Linux kernel development ?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-02-01T20:38:42Z","receivedAt":"2006-02-01T20:38:42Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Feb 01, 2006 at 12:38:44PM +0100, Laurent Pinchart wrote:\n> I have no idea how to layout my git repository to work on day-to-day \n> development. I need to :\n> \n> - commit bug fixes, external patches and internal modifications to a branch \n> (or possibly on separate branches depending on what I commit if needed). The \n> work will be based on Linux kernel 2.6.15 but I'd like to stay up-to-date \n> with the master repository as much as possible.\n> - push bug fixes upstream by creating a patchset and submitting it by email.\n> - pull changes from upstream and merge them in my various branches when the \n> upstream versions become stable enough.\n> - keep branches for all the versions shipped to the customers for bug fixes.\n> \n> I'm the only developer working on the Linux kernel in my company, but that \n> might change in a few months, so other developers will need to use git as \n> well.\n> \n> Is git able to accomodate my needs ?\n\nThose certainly sound like the kinds of things it's meant for.\n\n> I've been trying to setup a git repository with a few branches over\n> the last two days, but I always had to throw everything away and start\n> back from zero. I haven't been able to figure out which branches I\n> should create and how I should use them.\n\nMaybe you could be more specific about the problems you've had?\n\n--b.\n"},{"id":"15434","messageId":"7vmzha92lq.fsf@assigned-by-dhcp.cox.net","threadId":"3208","inReplyTo":"200602011238.44188.laurent.pinchart@tbox.biz","subject":"Re: How to use git for Linux kernel development ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T21:43:45Z","receivedAt":"2006-02-01T21:43:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Laurent Pinchart <laurent.pinchart@tbox.biz> writes:\n\n> ... I haven't been able to figure \n> out which branches I should create and how I should use them.\n\nBruce already responded to this part in a more polite way, but\nlet me be more blunt.  You need to figure out how your project\nand workflow is to be organized first, and that needs your own\nthinking.  We could help, but you know your project better than\nany of us.  The organization of what git branches to use and how\nwould fall out as a natural consequence of your workflow.\n\n> ... If really unable to use git, I'll go for SVN (or\n> SourceSafe as that's what my company used until today, but I'd\n> like to avoid it) even if I feel it will make keeping\n> up-to-date with upstream more difficult.\n\nAnd I suspect you would have the same workflow issues regardless\nof the choice of any SCM (some SCM may _force_ particular\nworkflow on you though; which may be a good thing -- it reduces\nconfusion coming from having too many possibilities to choose\nfrom).\n\nFor example, with my simplified world view, I would do something\nlike this:\n\nmaster::\n\tthe tip of the latest of your product.\n\nvanilla::\n\tthe tip of the Linus vanilla kernel. you do not\n        commit to it---you only update it via \"git fetch\".\n\nkfix::\n\tforked somewhere from refs/heads/vanilla, and may\n        occasionally be updated by merging from it, to\n        hold your own bugfixes meant for mainline.\n\nmaint/1.0, maint/1.1, maint/1.2,...::\n\tforked somewhere from master when you do a release.\n\n\nYour product specific work is done in master.  In practice, you\nprobably would emply \"topic branch\" workflow to grow the master,\nbut that is covered pretty well by Tony Luck in one of our howto\ndocuments, so I would not repeat it here. External patches you\npick up from elsewhere would go in the master as well.\n\nWhen working on bugs present in the vanilla kernel, You checkout\nkfix, work in there and commit fixes to this branch.  It may be\na good idea to occasionally sync this branch with vanilla when\nyour changes conflict with upstream changes.  This is the branch\nyou would publish to the outside world for consumption by the\nkernel community (other branches probably need to be published\nto satisfy your GPL obligations as well).\n\nYou would merge from kfix into master as needed.\n\nWhen you release your version 1.0 product, you would tag\n\"master\", and at the same time, branch \"maint/1.0\" from there.\nFurther post-release fixes you would commit to maint/1.0\nbranch.  You might make further tags 1.0.1, 1.0.2 on this branch\nas needed.\n"}]}