Now that we're all using git and hopefully most developer has started to get a feel for it I'd like us to move to a more git-like development model. For instance, it would be nice if we to a larger degree used micro commits and patch series with clean histories. Local topic branches and interactive rebases are a great way to achieve this, and git-bz[1] is a great way to interect with bugzilla in this fashion.
For people not used to git or how e.g. the kernel community uses it let me describe these things a bit. Implementing a feature often required multiple changes that are in themselves independent. For example, its not uncommon that a feature consists of these changes: * Move existing static function higher up so we can call it * Extend an existing function by adding a new parameter to it * Use the new parameter in one place to implement the new feature Historically these would all end up in one patch in cvs/svn, but with the cheap local commits and powerful features of git it would be better if this consisted of three commits, first one that just moves code, then we add the new parameter and pass in the default value for it everywhere, then another commit that uses the new parameter to implement the feature. Advantages of this is: * Easier to review * Nicer, easier to understand version history * using git bisect gives you more fine-grained information These kinds of commits leads naturally to the concept of patch series. Instead of one single patch implementing a new feature you use micro-commits as above and when done you use git format-patch to generate a series of patches for review/commit (automatically keeping author info and commit logs). In order to easily handle something like this topic branches are often used. A topic branch is a small, local only branch that contains only the commits related to a small feature. You can then use this branch to generate a patch series for review and/or commit, via e.g. git-bz (or git format-patch). Since the branch is local the developer is free to rebase it to e.g. rewrite history or move to a later base for the branch without affecting any other checkout. History rewriting is interesting here. We can use git while developing a feature and fix up things based on patch review, but at the end still get a clean history. For instance, if one patch in a series has a bug that gets caught in the review, then its pretty easy to commit a fix for it and then use interactive rebasing of the topic branch (git rebase -i origin) to squash the new commit into the commit that introduced the bug, thus never showing this bug to the world in the final merged history. If you want to submit such a patch series for review, then git-bz is an excellent way to manage patch attachements, both from the side that attaches the patches and the side that commits them to git. I'd recommend everyone to play with this a bit. [1] http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/ -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list
