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...
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
