Michael WittenOn Tue, Apr 27, 2010 at 20:59, John Tapsell <johnflux@gmail.com> wrote:
Show 5 quoted lines
> 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=2Specifically:
On Thu, Jan 28, 2010 at 15:03, Michael Witten <mfwitten@gmail.com> wrote:
Show 14 quoted lines
> 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:
Show 32 quoted lines
> 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:
Show 17 quoted lines
> 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