Re: Groups of commits (Übercommits)

On Tue, Apr 27, 2010 at 20:59, John Tapsell [off-list ref] 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 [off-list ref] 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 [off-list ref] 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 [off-list ref]
   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 [off-list ref] wrote:

On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten [off-list ref] wrote:

quoted

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