On Tue, Apr 27, 2010 at 20:59, John Tapsell <johnflux@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxx> wrote:
> On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten <mfwitten@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html