public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox•net>
To: Linus Torvalds <torvalds@osdl•org>
Cc: Git Mailing List <git@vger•kernel.org>,
	Paul Mackerras <paulus@samba•org>,
	Marco Costalba <mcostalba@yahoo•it>,
	Aneesh Kumar <aneesh.kumar@gmail•com>
Subject: Re: The merge from hell...
Date: Wed, 01 Feb 2006 23:05:46 -0800	[thread overview]
Message-ID: <7v8xsuuto5.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0602012212200.21884@g5.osdl.org> (Linus Torvalds's message of "Wed, 1 Feb 2006 22:28:56 -0800 (PST)")

Linus Torvalds <torvalds@osdl•org> writes:

>  I've been holding off on having octopus merges in the kernel tree, but I 
> just merged an ACPI update that had used one of them, and I didn't really 
> see any real reason not to take it.
>
> That octopus commit has got _twelve_ parents.

Len must have been smoking something really good.  Even I would
not attempt to do such an octopus and expect to keep my sanity,
but why not? ;-)

> It's commit 9fdb62af92c741addbea15545f214a6e89460865, and passing it to 
> git-diff-tree with the "--cc" option seems to do the largely the right 
> thing (although arguably, since one of the parents always matches the end 
> result in all the files, it shouldn't have shown anything at all, so I 
> think it could do with some tweaking).

Hmph.  Do you mean a hunk like this?

diff --cc kernel/sys.c
@@@@@@@@@@@@@ +33,7 @@@@@@@@@@@@@

            #include <linux/compat.h>
            #include <linux/syscalls.h>
   + +++    #include <linux/kprobes.h>

            #include <asm/uaccess.h>
            #include <asm/io.h>

Currently I cull hunks that have changes from only one parent,
or when the changes are the same from all but one parent.  This
hunk does not match either criteria.

Instead I could cull all hunks that have either "all whitespace"
or "plus and minus in the same set of columns" hunks.  If I did
so, this would become uninteresting:

diff --cc arch/ia64/pci/pci.c
@@@@@@@@@@@@@ +709,7 @@@@@@@@@@@@@
             */
            int ia64_pci_legacy_write(struct pci_dev *bus, u16...
            {
  ------ -  	int ret = 0;
  ++++++ +  	int ret = size;
            
            	switch (size) {
            	case 1:

But this is still interesting:

@@@@@@@@@@@@@ +308,35 @@@@@@@@@@@@@
            			goto end;
            		}
            	}
  --        	cx->usage++;
  --        
            
     +++    #ifdef CONFIG_HOTPLUG_CPU
     +++    	/*


> git-diff-tree takes almost three seconds to get its result, though.

One trivial thing I should be able to do to speed things up is
to reuse previous diff with other parents.  For example, that
commit does this to kernel/sys.c from its 12 parents.

:100644 100644 d09cac2... 0929c69... M  kernel/sys.c
:100644 100644 eecf845... 0929c69... M  kernel/sys.c
:100644 100644 c3b1874... 0929c69... M  kernel/sys.c
:100644 100644 bce933e... 0929c69... M  kernel/sys.c
:100644 100644 eecf845... 0929c69... M  kernel/sys.c
:100644 100644 bce933e... 0929c69... M  kernel/sys.c
:100644 100644 bce933e... 0929c69... M  kernel/sys.c
:100644 100644 bce933e... 0929c69... M  kernel/sys.c
:100644 100644 eecf845... 0929c69... M  kernel/sys.c
:100644 100644 eecf845... 0929c69... M  kernel/sys.c
:100644 100644 eecf845... 0929c69... M  kernel/sys.c
:100644 100644 eecf845... 0929c69... M  kernel/sys.c

Running "sort -u" on these would leave only 4 lines.

I did not expect anybody to be _that_ sick (eh, pardon my
language) to do a 12-way octpus, so I did not consider this
optimization possibility, but I should be doing only 4 diffs to
format -c for this commit.  Currently I do 12.

> So think of it as a correctness/scalability test.

Heh.  I like this one as a practice.  Thanks!

  reply	other threads:[~2006-02-02  7:05 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-02  6:28 The merge from hell Linus Torvalds
2006-02-02  7:05 ` Junio C Hamano [this message]
2006-02-02  7:40   ` [PATCH] combine-diff: reuse diff from the same blob Junio C Hamano
2006-02-02  7:51   ` The merge from hell Linus Torvalds
2006-02-02  7:55     ` Linus Torvalds
2006-02-02  8:08       ` Linus Torvalds
2006-02-02  8:18         ` [PATCH] combine-diff: update --cc "uninteresting hunks" logic Junio C Hamano
2006-02-02  9:34           ` [PATCH] combine-diff: add safety check to --cc Junio C Hamano
2006-02-02 23:03             ` Linus Torvalds
2006-02-03  0:02               ` Junio C Hamano
2006-02-03  1:05                 ` Linus Torvalds
2006-02-03  5:49                 ` [Attn - repository browser authors] diff-tree combined format Junio C Hamano
2006-02-03 12:17                   ` Marco Costalba
2006-02-03 19:55                     ` Junio C Hamano
2006-02-03 21:35                     ` Junio C Hamano
2006-02-04 12:03                       ` Marco Costalba
2006-02-04 11:23                   ` Paul Mackerras
2006-02-03  5:28               ` [PATCH] combine-diff: add safety check to --cc Junio C Hamano
2006-02-04  5:38               ` Paul Mackerras
2006-02-04  6:12                 ` Junio C Hamano
2006-02-04 10:46   ` The merge from hell Paul Mackerras
2006-02-04 12:22     ` Junio C Hamano
2006-02-04 19:42     ` Linus Torvalds
2006-02-04 20:59       ` Linus Torvalds
2006-02-02  7:25 ` Marco Costalba
2006-02-02  8:02   ` Linus Torvalds
2006-02-02  8:07     ` Aneesh Kumar
2006-02-02  8:27       ` Junio C Hamano
2006-02-02  8:44       ` Linus Torvalds
2006-02-02 10:41         ` Junio C Hamano
2006-02-05 19:42           ` Linus Torvalds
2006-02-05 19:49             ` Add a "git show" command to show a commit Linus Torvalds
2006-02-05 19:58               ` Fix git-rev-parse over-eager errors Linus Torvalds
2006-02-05 20:11                 ` Junio C Hamano
2006-02-05 22:03                   ` Linus Torvalds
2006-02-06  6:20                     ` Junio C Hamano
2006-02-05 22:45               ` Add a "git show" command to show a commit Junio C Hamano
2006-02-05 22:55                 ` Linus Torvalds
2006-02-05 22:59                   ` Linus Torvalds
2006-02-06  0:25                     ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2006-02-03  4:20 The merge from hell Brown, Len
2006-02-03  5:45 ` Linus Torvalds
2006-02-03  6:28   ` Junio C Hamano
2006-02-03 16:21     ` Dave Jones
2006-02-03  6:04 Brown, Len
2006-02-03  6:16 ` Linus Torvalds
2006-02-03  6:33   ` Junio C Hamano
2006-02-03  6:41 linux
2006-02-03 18:34 Brown, Len
2006-02-04  2:35 ` Junio C Hamano
2006-02-04  2:47   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v8xsuuto5.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox$(echo .)net \
    --cc=aneesh.kumar@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=mcostalba@yahoo$(echo .)it \
    --cc=paulus@samba$(echo .)org \
    --cc=torvalds@osdl$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox