{"thread":{"id":"23626","subject":"Re: Groups of commits (Übercommits)","startedAt":"2010-04-28T08:35:07Z","lastAt":"2010-04-28T08:35:07Z","messageCount":1,"participants":["Michael Witten"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140571","messageId":"l2nb4087cc51004280135hdb8d3c7cjd53aca912840b6bf@mail.gmail.com","threadId":"23626","inReplyTo":null,"subject":"Re: Groups of commits (Übercommits)","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-28T08:35:07Z","receivedAt":"2010-04-28T08:35:07Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, Apr 27, 2010 at 20:59, John Tapsell <johnflux@gmail.com> wrote:\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\nJust for the record, I brought up such an idea in another thread; I\ncalled them übercommits:\n\n    http://marc.info/?l=git&m=126470903523316&w=2\n    http://marc.info/?l=git&m=126471007125357&w=2\n    http://marc.info/?l=git&m=126471096827004&w=2\n\nSpecifically:\n\nOn Thu, Jan 28, 2010 at 15:03, Michael Witten <mfwitten@gmail.com> wrote:\n> I've been thinking for a while that it would be useful to\n> have übercommits (they don't exist) that are treated like single\n> commits but that actually encapsulate multiple continguous commits.\n>\n> ...\n>\n> These übercommits would also allow developers to make a string of\n> commits that by themselves break things but together formulate a\n> complete solution; because the übercommits encapsulate the breakage,\n> bisection would still be simple (no fear of dealing with broken\n> commits), but the small manageable commits would still be available\n> for references and manipulation.\n>\n> Perhaps trees could be reappropriated for the implementation of übercommits.\n\nOn Thu, Jan 28, 2010 at 15:20, Michael Witten <mfwitten@gmail.com> wrote:\n\n> In fact, the commit message body is already being used to create\n> unofficial übercommits. Consider a common merge commit from a\n> clone of Linus's Linux repo:\n>\n>    commit e80b1359858df17b0034bdf7d1b6f3e0d5b97257\n>    Merge: 341031c b27d515\n>    Author: Linus Torvalds <torvalds@linux-foundation.org>\n>    Date:   Thu Jan 21 08:50:04 2010 -0800\n>\n>        Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip\n>\n>        * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:\n>          perf: x86: Add support for the ANY bit\n>          perf: Change the is_software_event() definition\n>          perf: Honour event state for aux stream data\n>          perf: Fix perf_event_do_pending() fallback callsite\n>          perf kmem: Print usage help for unknown commands\n>          perf kmem: Increase \"Hit\" column length\n>          hw-breakpoints, perf: Fix broken mmiotrace due to dr6 by reference change\n>          perf timechart: Use tid not pid for COMM change\n>\n> It seems like this kind of useful information should be a more\n> integral part of the metadata.\n>\n> Indeed, it seems like commit messages are often used for metadata\n> that git perhaps *should* handle natively, like sign-offs and\n> multiple Authors, etc.\n>\n> Of course, I'm betting that git doesn't handle such things\n> officially because it would require more general data structures\n> (especially for variable numbers of Authors) and thus slower\n> algorithms.\n\nOn Thu, Jan 28, 2010 at 15:35, Michael Witten <mfwitten@gmail.com> wrote:\n\n> On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten <mfwitten@gmail.com> wrote:\n>> These übercommits would also allow developers to make a string of\n>> commits that by themselves break things but together formulate a\n>> complete solution; because the übercommits encapsulate the breakage,\n>> bisection would still be simple (no fear of dealing with broken\n>> commits), but the small manageable commits would still be available\n>\n> As a corollary to this, developers can maintain patch integrity.\n>\n> Quite often, I've sent a patch off to some project only to have\n> the maintainer `tweak' the result before making a commit. However,\n> I frankly don't want my name attached to someone else's work,\n> because I may disagree with what has been done.\n>\n> Were übercommits available, the maintainer could commit my original\n> work and then make a new `tweak' commit and then bundle the 2 together\n> as an übercommit in order to encapsulate this series of events.\n\nSincerely,\nMichael Witten\n"}]}