Ext4 Kernel patches
The ext4 git tree
The three branch pointers which are important on the
ext4 tree are origin, master, and dev. The origin branch is where we have branched off of Linus's tree. At the moment, ext4/origin is pointing at v3.8-rc3. The ext4/master branch is always between origin and dev (inclusive). The dev branch is a rewinding branch, which means that everything between master and dev may be get modified (i.e., to add a Reviewed-by: or to fix up some comments, etc.), or may get dropped (if it turns out we discover the patch is not ready for prime time). The dev branch is also what gets included into linux-next.
The master branch represents those patches which have been "finalized", which means once we bump the master branch, all of the commits between origin and master (inclusive) are guaranteed not to change. So for people who are building on top of master, it's safe for them to use git. For people who are building on top of dev, if you want to make changes, it's recommended you use a tool like quilt, guilt, or stgit.
The ext4 patch queue
The patch queue is used to create the dev branch. The dev branch can be replicated as follows:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ext4
$ mkdir -p ext4/.git/patches
$ cd ext4/.git/patches
$ git clone git://repo.or.cz/ext4-patch-queue.git dev
$ cd dev
$ sh timestamps
$ cd ../../..
$ git branch dev $(head -1 .git/patches/dev/series | sed -e 's/# BASE //')
$ git checkout dev
$ guilt push stable-boundary
$ guilt pop
The patch queue series is divided into stable and unstable patches. The stable patches are the ones usually used to push back upstream, while the unstable section has the patches for development purposes only and are not ready for pushing upstream (and some may never make it in). File series marks status of each patch.
E2fsprogs git repository
The e2fsprogs git repository can be found here:
There is also a patch queue for the 64-bit patches available here:
Here is an email from Aneesh Kumar K.V explaining different branches in git tree.
I gues Ted is following the same terminology. http://marc.info/?l=git&m=117965490313979&w=2
There are four branches in git.git repository that track the source tree of git: "master", "maint", "next", and "pu". I may add more maintenance branches (e.g. "maint-1.5.1") if we have huge backward incompatible feature updates in the future to keep an older release alive; I may not, but the distributed nature of git means any volunteer can run a stable-tree like that himself.
The "master" branch is meant to contain what are very well tested and ready to be used in a production setting. There could occasionally be minor breakages or brown paper bag bugs but they are not expected to be anything major. Every now and then, a "feature release" is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was v1.5.2 done on May 20th this year.
Whenever a feature release is made, "maint" branch is forked off from "master" at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are named with four dotted decimal, named after the feature release they are updates to; the last such release was v220.127.116.11. New features never go to this branch. This branch is also merged into "master" to propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master". A new development, either initiated by myself or more often by somebody who found his or her own itch to scratch, does not usually happen on "master", however. Instead, a separate topic branch is forked from the tip of "master", and it first is tested in isolation; I may make minimum fixups at this point. Usually there are a handful such topic branches that are running ahead of "master" in git.git repository. I do not publish the tip of these branches in my public repository, however, partly to keep the number of branches that downstream developers need to worry about low, and primarily because I am lazy.
I judge the quality of topic branches, taking advices from the mailing list discussions. Some of them start out as "good idea but obviously is broken in some areas (e.g. breaks the existing testsuite)" and then with some more work (either by the original contributor or help from other people on the list) becomes "more or less done and can now be tested by wider audience". Luckily, most of them start out in the latter, better shape.
The "next" branch is to merge and test topic branches in the latter category. In general, the branch always contains the tip of "master". It might not be quite rock-solid production ready, but is expected to work more or less without major breakage. I usually use "next" version of git for my own work, so it cannot be _that_ broken to prevent me from pushing the changes out. The "next" branch is where new and exciting things take place.
The above three branches, "master", "maint" and "next" are never rewound, so you should be able to safely track them (this automatically means the topics that have been merged into "next" are not rebased, and you can find the tip of topic branches you are interested in from the output of "git log next").
The "pu" (proposed updates) branch bundles all the remainder of topic branches. The "pu" branch, and topic branches that are only in "pu", are subject to rebasing in general.
When a topic that was in "pu" proves to be in testable shape, it graduates to "next". I do this with:
git checkout next git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so hot and the topic can be dropped from "pu" in such a case.
A topic that is in "next" is expected to be tweaked and fixed to perfection before it is merged to "master" (that's why "master" can be expected to stay very stable). Similarly to the above I do it with this:
git checkout master git merge that-topic-branch git branch -d that-topic-branch
However, being in "next" is not a guarantee to appear in the next release (being in "master" is such a guarantee, unless it is later found seriously broken and reverted), or even in any future release. There even were cases that topics needed reverting a few commits in them before graduating to "master", or a topic that already was in "next" were entirely reverted from "next" because fatal flaws were found in them later.