| |||||||||||||
The current development kernel is...linux-next?The current development kernel is...linux-next?Posted Jul 8, 2008 22:14 UTC (Tue) by iabervon (subscriber, #722)Parent article: The current development kernel is...linux-next?
I think Andrew is just wrong about what people should be developing against. If you develop against -next, then your changes won't be acceptable for inclusion in -next if there are conflicts, because of the way -next is generated. If, for example, after you start working, some series that was already in -next gets revised, your tree will now generate a slew of conflicts in code you've never looked at, because you'll have Stephen merge all of that particular old -next plus your series with the current -next when he pulls, and do it as if the two -next versions were developed independently. What would be more useful is to develop based on what -next bases on, but test the merge of your code and -next, and make that merge available. That gets the development history clean and clear, checks that integration with the rest of -next works, tests that the rest of -next works for you, and also should allow git to get information on the proper merge with various -next versions so that the integration is smoother.
(Log in to post comments)
How to develop against linux-next Posted Jul 9, 2008 15:16 UTC (Wed) by jejb (subscriber, #6654) [Link] I assume from your comments that you're using git not quilt? (since quilt doesn't really care if you change the tree under it, you just do a quilt pop -a; install new tree; quilt push -a) The way to develop against linux-next in git is to use git rebase --onto to move your patches as linux-next changes. So, assume you have a git tree with your patches on the master branch. You also need to record the base of your branch with either a tag or a branch (you do this before you start adding patches) so that git format-patch base produces exactly all the patches you're managing. The way I set this up is to clone a tree (git clone <tree>) record the base (git branch base) and simply develop committing along the way. Now set up remote tracking branches (I tend to do one for linux-next and one for linus as): git remote add -t master -f linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git remote add -t master -f next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git The point of keeping the linus tree is that eventually all the branches that comprise next are merged into linus, at which point your patches will be ready for submission against vanilla linus. To download the current trees of the day, simply do a git remote update and to put your patches onto the current linux-next do git rebase --onto remotes/next/master base If this is successfully completed, you need to record the fact that you've moved the base of your patches: git branch -M base remotes/next/master You can keep doing this as many times as linux-next updates. If you think you're ready to try to place your patches onto vanilla linus, just repeat the recipe but with remotes/linus/master instead of remotes/next/master. If your attempt to rebase onto linus fails (usually because of missing commits that were in linux-next that you're relying on) simply do git rebase --abort.
How to develop against linux-next Posted Jul 9, 2008 17:44 UTC (Wed) by iabervon (subscriber, #722) [Link] The problem isn't that developing against a rebasing tree is too difficult, because it's generally not too hard to update things. The problem is that developing against a rebasing tree generates a repository which isn't suitable for inclusion in the rebasing tree. That is, following your instructions would be fine if -next weren't a useful tree to try to get your stuff into, but the resulting repository isn't something that Stephen can pull into -next. I suppose if you're targeting 2.6.n+3 (or later) for inclusion, you could develop against -next, but that's sort of pessimistic. And I think that, if it makes sense to publish your changes at all, it makes sense to have them in a state where they go against vanilla linus. Also note that, if you develop against -next, either it doesn't matter, because you don't have any interactions with other people's changes, or you're going to waste a lot of time when a tree that you interact with gets some conflict and Stephen drops it (requiring you to resolve a slew of conflicts) and then picks it up again the next day (requiring you to resolve the same slew of conflicts the other way, back to essentially the state you had before). And that applies to quilt as well; quilt will happily let the base change under it, but you'll have days when your code won't work without a pile of fixups, and the "bug" it will be due to is that some code that you now require is temporarily and intentionally missing.
How to develop against linux-next Posted Jul 9, 2008 19:14 UTC (Wed) by jejb (subscriber, #6654) [Link] Well, if you're running a development tree, it isn't eligible for inclusion into linux-next, since linux-next only consists of everything that will go in in the next merge window. What you'd be developing this way is a patch series being posted to a mailing list and refined. Once it's ready for inclusion, and everyone's signed off, then you get your own tree or send them to a subsystem maintainer (and usually the latter if you have conflicts against linus because you need to go through the tree of the subsystem you're in conflict with). With this method of development, you can be targeting 2.6.n+1 since the delta between linus and linux-next goes to zero within the merge window. The whole point of developing against linux next is to see where you do pick up conflicts. If you do and you don't resolve them (which the rebasing method allows you to), Linus is hardly going to choose to merge your tree over the subsystem tree you just conflicted with. It's far easier to resolve conflicts incrementally (as in daily) than wait for weeks and see how bad it becomes (believe me, I've done both).
How to develop against linux-next Posted Nov 13, 2011 18:50 UTC (Sun) by cheako (guest, #81350) [Link]
I've some newb questions, just act like I'm dumb and any one explain it to me, please.
What tree should be cloned? Does one clone linux-next and then configure it as a remote?
What's the reason for "git branch base" prior to configuring the remotes?
Reading the help files is confusing, I belief I'll only learn via experience.
# git2.kernel.org
Must have sent null byte first?
How to develop against linux-next Posted Nov 13, 2011 20:46 UTC (Sun) by cheako (guest, #81350) [Link]
This is the way git says "Repo not found."
How to develop against linux-next Posted Nov 13, 2011 20:43 UTC (Sun) by cheako (guest, #81350) [Link]
Linux-Next is has [1]moved from the old location.
1. git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
How to develop against linux-next Posted Nov 13, 2011 20:56 UTC (Sun) by cheako (guest, #81350) [Link] An example:mkdir -p ~/src/kernel/ cd ~/src/kernel/ git init linux-next cd linux-next git remote add -t master -f linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git remote add -t master -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git checkout remotes/next/master git branch base # vi/edit/commit/*rebase/view/ect till your harts content.* Rebase done using instructions in original article, AFAIK.
|
|||||||||||||