{"thread":{"id":"23625","subject":"Groups of commits","startedAt":"2010-04-28T01:59:44Z","lastAt":"2010-04-28T12:46:03Z","messageCount":6,"participants":["John Tapsell","Jeff King","Michael Poole","Tay Ray Chuan","Alex Riesen","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140560","messageId":"j2u43d8ce651004271859t8f306261n330004142a42b6df@mail.gmail.com","threadId":"23625","inReplyTo":null,"subject":"Groups of commits","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2010-04-28T01:59:44Z","receivedAt":"2010-04-28T01:59:44Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"Hi all,\n\n In my work place, we have a lot of strict rules to get something\ncommitted. The code has to pass against a large test suite, it has to\nbe tested on different hardware, and so on.\n\n The problem is that it forces everyone to have one single large\ncommit for a week's work. All the intermediate stages get squashed\nand that history forever lost.\n\n It would be nice to have a commit in the repository, treated as a\nsingle commit for all purposes, but then be able to split it into\nmultiple commits if necessary.\n\n Any ideas?\n\nJohn\n"},{"id":"140562","messageId":"20100428021431.GD16107@coredump.intra.peff.net","threadId":"23625","inReplyTo":"j2u43d8ce651004271859t8f306261n330004142a42b6df@mail.gmail.com","subject":"Re: Groups of commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-28T02:14:31Z","receivedAt":"2010-04-28T02:14:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 28, 2010 at 10:59:44AM +0900, John Tapsell wrote:\n\n> In my work place, we have a lot of strict rules to get something\n> committed. The code has to pass against a large test suite, it has to\n> be tested on different hardware, and so on.\n> \n> The problem is that it forces everyone to have one single large\n> commit for a week's work. All the intermediate stages get squashed\n> and that history forever lost.\n\nRedefine \"committed\" to be \"merged to the mainline branch\" (or\n\"committed to the mainline branch\" if you need to keep the nomenclature\nto please pointy-haired people). Have everybody work on their own branch\neach week (or better yet, a branch per topic).\n\nWhen they would make their single big commit, instead \"git merge\n--no-ff\" from the topic branch into mainline. Do your tests on the\nresult. If it fails, kick back an error (or whatever you do now). If it\nworks, then add that merge commit to mainline.\n\nIf you want to see the \"big commits\", follow \"log --first-parent\" of the\nmainline branch. These commits will all pass the test suite. If you want\nto see the whole history, then use regular history browsing. Commits on\nside-branches do not necessarily pass the test suite.\n\n> It would be nice to have a commit in the repository, treated as a\n> single commit for all purposes, but then be able to split it into\n> multiple commits if necessary.\n\nMy suggestion above is not exactly what you asked for. It treats the\nhistory as multiple commits most of the time, but using --first-parent\nyou can ask for just the big commits.\n\n-Peff\n"},{"id":"140563","messageId":"87sk6ge312.fsf@troilus.org","threadId":"23625","inReplyTo":"j2u43d8ce651004271859t8f306261n330004142a42b6df@mail.gmail.com","subject":"Re: Groups of commits","fromName":"Michael Poole","fromEmail":"mdpoole@troilus.org","sentAt":"2010-04-28T02:15:05Z","receivedAt":"2010-04-28T02:15:05Z","isPatch":false,"sender":{"key":"mdpoole@troilus.org","avatar":null},"body":"John Tapsell writes:\n\n> Hi all,\n>\n> In my work place, we have a lot of strict rules to get something\n> committed. The code has to pass against a large test suite, it has to\n> be tested on different hardware, and so on.\n>\n> The problem is that it forces everyone to have one single large\n> commit for a week's work. All the intermediate stages get squashed\n> and that history forever lost.\n>\n> It would be nice to have a commit in the repository, treated as a\n> single commit for all purposes, but then be able to split it into\n> multiple commits if necessary.\n>\n> Any ideas?\n\nIsn't that what topic branches are for? When development is done on a\nshort-lived branch (hopefully one with a descriptive name), the only\ncommit that needs to go through that process is the merge onto the\nintegration branch.\n\nMichael Poole\n"},{"id":"140565","messageId":"r2jbe6fef0d1004272225rd61ef84axe86ba45a0b352a8@mail.gmail.com","threadId":"23625","inReplyTo":"87sk6ge312.fsf@troilus.org","subject":"Re: Groups of commits","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-04-28T05:25:39Z","receivedAt":"2010-04-28T05:25:39Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"On Wed, Apr 28, 2010 at 10:15 AM, Michael Poole wrote:\n> John Tapsell writes:\n>\n>> Hi all,\n>>\n>>   In my work place, we have a lot of strict rules to get something\n>> committed.  The code has to pass against a large test suite, it has to\n>> be tested on different hardware, and so on.\n>>\n>>   The problem is that it forces everyone to have one single large\n>> commit for a week's work.  All the intermediate stages get squashed\n>> and that history forever lost.\n>>\n>>   It would be nice to have a commit in the repository, treated as a\n>> single commit for all purposes, but then be able to split it into\n>> multiple commits if necessary.\n>>\n>>   Any ideas?\n>\n> Isn't that what topic branches are for?  When development is done on a\n> short-lived branch (hopefully one with a descriptive name), the only\n> commit that needs to go through that process is the merge onto the\n> integration branch.\n\nJust to add to the \"merge in topic branches\" idea - if you find that\nthe commits are trivially fast-forwardable, you can still add a short\nnote/cover letter with\n\n git merge --no-ff -m \"Added in foo's work\" \n\n-- \nCheers,\nRay Chuan\n"},{"id":"140570","messageId":"y2t81b0412b1004280105p46962bdeq163bc4fb92cb0fdb@mail.gmail.com","threadId":"23625","inReplyTo":"r2jbe6fef0d1004272225rd61ef84axe86ba45a0b352a8@mail.gmail.com","subject":"Re: Groups of commits","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2010-04-28T08:05:39Z","receivedAt":"2010-04-28T08:05:39Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Wed, Apr 28, 2010 at 07:25, Tay Ray Chuan wrote:\n> Just to add to the \"merge in topic branches\" idea - if you find that\n> the commits are trivially fast-forwardable, you can still add a short\n> note/cover letter with\n>\n>  git merge --no-ff -m \"Added in foo's work\" \n>\n\nExcept that is not a \"short note\" anymore, but a full-fledged merge\ncommit. You forced it with \"--no-ff\".\n"},{"id":"140589","messageId":"i2k32541b131004280546j5fc4e160oa1618fe14d83a291@mail.gmail.com","threadId":"23625","inReplyTo":"y2t81b0412b1004280105p46962bdeq163bc4fb92cb0fdb@mail.gmail.com","subject":"Re: Groups of commits","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-04-28T12:46:03Z","receivedAt":"2010-04-28T12:46:03Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Apr 28, 2010 at 4:05 AM, Alex Riesen wrote:\n> On Wed, Apr 28, 2010 at 07:25, Tay Ray Chuan wrote:\n>> Just to add to the \"merge in topic branches\" idea - if you find that\n>> the commits are trivially fast-forwardable, you can still add a short\n>> note/cover letter with\n>>\n>>  git merge --no-ff -m \"Added in foo's work\" \n>\n> Except that is not a \"short note\" anymore, but a full-fledged merge\n> commit. You forced it with \"--no-ff\".\n\nI think it's safe to say that a commit *is* just a \"short note\" about\na tree, who made it, the reason (message), and who its parents were.\n\nHave fun,\n\nAvery\n"}]}