On Wed, Apr 28, 2010 at 10:59:44AM +0900, John Tapsell wrote: > In my work place, we have a lot of strict rules to get something > committed. The code has to pass against a large test suite, it has to > be tested on different hardware, and so on. > > The problem is that it forces everyone to have one single large > commit for a week's work. All the intermediate stages get squashed > and that history forever lost. Redefine "committed" to be "merged to the mainline branch" (or "committed to the mainline branch" if you need to keep the nomenclature to please pointy-haired people). Have everybody work on their own branch each week (or better yet, a branch per topic). When they would make their single big commit, instead "git merge --no-ff" from the topic branch into mainline. Do your tests on the result. If it fails, kick back an error (or whatever you do now). If it works, then add that merge commit to mainline. If you want to see the "big commits", follow "log --first-parent" of the mainline branch. These commits will all pass the test suite. If you want to see the whole history, then use regular history browsing. Commits on side-branches do not necessarily pass the test suite. > It would be nice to have a commit in the repository, treated as a > single commit for all purposes, but then be able to split it into > multiple commits if necessary. My suggestion above is not exactly what you asked for. It treats the history as multiple commits most of the time, but using --first-parent you can ask for just the big commits. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html