Or Continue to Thread: Android Dev. How-To Guide: Com…
Find Your Device:
17th January 2012, 09:55 PM   |  #125  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 24,932
13,578 posts
Join Date:Joined: Aug 2007
Donate to Me
I'd strongly recommend adding some documentation on using git - any kernel developer should be using git to maintain their kernels. It makes bringing in upstream patches MUCH easier, and also publishing source is a lot easier.

Doing "git push origin" to a public repository like github or gitorious (I prefer github, gitorious seems buggy to me) take a LOT less time and bandwidth than pushing an entire new tarball for a given kernel release.

A few git tips:
  • Try to keep changes to "one feature, one commit". In addition to making the lives of other developers who want to apply your feature to another device easier, it will make your OWN life easier if you start working on another device.
  • Keep defconfig changes separate from the kernel commit that adds the feature being enabled/disabled/configured using the defconfig change. Otherwise the defconfig change will make the commit unlikely to apply cleanly to another source tree
  • To get a properly formatted git-am commitable patch, append .patch to the URL of a github page - example: https://github.com/Entropy512/linux_...d184a43107bb67 becomes https://github.com/Entropy512/linux_...3107bb67.patch
  • Patches made as described above can be committed using "git am filename.patch" - this preserves attribution to the original author of the commit. It's not required (Edit: Actually, on further thought, some of the legal rules relating to copyrights may require that authorship be preserved - better safe than sorry!) but a nice thing to do and makes other kernel maintainers more likely to cooperate with you. They may even start coming to your kernel thread and posting useful patches.
  • DO NOT rebase commits you've already pushed to a public repo, this practice is considered mortal git-sin, even Torvalds has written rants against this practice - Worst case this means more than one commit for a given feature. (e.g. initial feature commit, cleanup/bugfix commit). If you do this, ideally reference the commit you're fixing up.
  • When reverting something, make a comment why you're doing the revert - Otherwise someone will wonder what was wrong with the feature you reverted
  • In general, try to be descriptive with your changes in the commit description - what you're changing and why - I suggest doing some research and looking at how commits are made on the mainline Linux kernel.

One which I should be doing, but have been lazy about:
When you do a release, you can tag that branch/revision so it is easily identifiable as the branch for this release. I admit I haven't done this nearly as often as I should.
Last edited by Entropy512; 23rd April 2013 at 09:31 PM.
The Following 53 Users Say Thank You to Entropy512 For This Useful Post: [ View ]