Hi: * Rene Herman <rene.herman@xxxxxxxxxxxx> [2007-10-29 20:45:04 +0100]: > On 10/28/2007 11:48 AM, Robert P. J. Day wrote: > > > at the moment, i have a sizable patch set for this new feature that > >applies cleanly against the 2.6.23 kernel, but that's definitely going > >to need some hacking to make it apply cleanly against the current git > >pull. so, to make this work, what would be the correct order of > >operations? based on my brief perusal, it would seem that i would > >initialize my git repo with just the latest kernel git pull (and > >nothing more), so my initial git repo would contain absolutely nothing > >related to that new feature, and anyone pulling from it would get, > >well, nothing. > > > > then, little by little, i'd start adding and committing new features > >in my tree, and when people pulled from my tree, they'd get that > >additional content which, as long as i'm keeping up to date against > >the main kernel git repo, should apply cleanly against *their* trees. > >is that about right? > > It would seem so yes. I've been using git locally for a while now, not for > publishing trees/changes to others, so seeing as how that's your eventual > goal you should allow for others who do use it in that capacity to tell you > otherwise but after the initial clone from Linus' master tree, I'd branch > off at that point to keep the local work in a seperate branch: > > $ git clone > git://git2.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git local > $ cd local > $ git checkout -b x86_128 > Switched to a new branch "x86_128" > > do a "git checkout -b x86_128 v2.6.23" for any value of <tag> if you want > to branch of at a specific release. > > The "master" branch at this point will be a pristine upstream tree and > you'd work in the "x86_128" branch. If you do this, then in this branch you > will have a nicely undisturbed linear history of your code while if you'd > work directly on the master branch, each time you'd pull from upstream > again you'd get it all intermixed in the log. Then every once in a while > you'd rebase (git rebase) to a new upstream... Keep in mind, git-rebase rewrites history. You should not do this on a public branch unless you inform people so they can deal with it properly. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-with-rewriting-history In a nutshell... whenever you rewrite history, people downstream from you will need to blow away their copy of your branch and re-fetch the whole thing. It's not a big deal for testers. But, if there are devs working patches on top of yours, they'll have some extra work to do when you rebase. For my public hwmon git tree, I have two branches: testing and release. The testing branch gets all new patches; I always rebase it to the latest tag. Andrew pulls from this one for -mm; he expects the history to be non-linear. (Or more precisely, he doesn't care. AFAIK he just extracts a patch out of that and then builds -mm using quilt.) When I'm ready to send stuff to Linus, it gets pulled or cherry-picked into the release branch. That one is *never* rebased (unless I screw up). I'm sure there are other ways to do it, but anyway that's my routine. HTH Regards, -- Mark M. Hoffman mhoffman@xxxxxxxxxxxxx -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
