Re: Questions about branches in git

[Michael Witten <mfwitten@gmail.com>]

On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
> However, 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.

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.

Sincerely,
Michael Witten