On Wed, Apr 28, 2010 at 10:15 AM, Michael Poole <mdpoole@xxxxxxxxxxx> wrote: > John Tapsell writes: > >> Hi all, >> >> 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. >> >> 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. >> >> Any ideas? > > Isn't that what topic branches are for? When development is done on a > short-lived branch (hopefully one with a descriptive name), the only > commit that needs to go through that process is the merge onto the > integration branch. Just to add to the "merge in topic branches" idea - if you find that the commits are trivially fast-forwardable, you can still add a short note/cover letter with git merge --no-ff -m "Added in foo's work" <branch/commit> -- Cheers, Ray Chuan -- 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