Re: Groups of commits (Übercommits)

[Michael Witten <mfwitten@gmail.com>]

On Tue, Apr 27, 2010 at 20:59, John Tapsell <johnflux@gmail.com> wrote:
>  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?

Just for the record, I brought up such an idea in another thread; I
called them übercommits:

    http://marc.info/?l=git&m=126470903523316&w=2
    http://marc.info/?l=git&m=126471007125357&w=2
    http://marc.info/?l=git&m=126471096827004&w=2

Specifically:

On Thu, Jan 28, 2010 at 15:03, Michael Witten <mfwitten@gmail.com> wrote:
> I've been thinking for a while that it would be useful to
> have übercommits (they don't exist) that are treated like single
> commits but that actually encapsulate multiple continguous commits.
>
> ...
>
> These übercommits would also allow developers to make a string of
> commits that by themselves break things but together formulate a
> complete solution; because the übercommits encapsulate the breakage,
> bisection would still be simple (no fear of dealing with broken
> commits), but the small manageable commits would still be available
> for references and manipulation.
>
> Perhaps trees could be reappropriated for the implementation of übercommits.

On Thu, Jan 28, 2010 at 15:20, Michael Witten <mfwitten@gmail.com> wrote:

> In fact, the commit message body is already being used to create
> unofficial übercommits. Consider a common merge commit from a
> clone of Linus's Linux repo:
>
>    commit e80b1359858df17b0034bdf7d1b6f3e0d5b97257
>    Merge: 341031c b27d515
>    Author: Linus Torvalds <torvalds@linux-foundation.org>
>    Date:   Thu Jan 21 08:50:04 2010 -0800
>
>        Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
>
>        * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
>          perf: x86: Add support for the ANY bit
>          perf: Change the is_software_event() definition
>          perf: Honour event state for aux stream data
>          perf: Fix perf_event_do_pending() fallback callsite
>          perf kmem: Print usage help for unknown commands
>          perf kmem: Increase "Hit" column length
>          hw-breakpoints, perf: Fix broken mmiotrace due to dr6 by reference change
>          perf timechart: Use tid not pid for COMM change
>
> It seems like this kind of useful information should be a more
> integral part of the metadata.
>
> Indeed, it seems like commit messages are often used for metadata
> that git perhaps *should* handle natively, like sign-offs and
> multiple Authors, etc.
>
> Of course, I'm betting that git doesn't handle such things
> officially because it would require more general data structures
> (especially for variable numbers of Authors) and thus slower
> algorithms.

On Thu, Jan 28, 2010 at 15:35, Michael Witten <mfwitten@gmail.com> wrote:

> On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
>> These übercommits would also allow developers to make a string of
>> commits that by themselves break things but together formulate a
>> complete solution; because the übercommits encapsulate the breakage,
>> bisection would still be simple (no fear of dealing with broken
>> commits), but the small manageable commits would still be available
>
> As a corollary to this, developers can maintain patch integrity.
>
> Quite often, I've sent a patch off to some project only to have
> the maintainer `tweak' the result before making a commit. However,
> I frankly don't want my name attached to someone else's work,
> because I may disagree with what has been done.
>
> Were übercommits available, the maintainer could commit my original
> work and then make a new `tweak' commit and then bundle the 2 together
> as an übercommit in order to encapsulate this series of events.

Sincerely,
Michael Witten