git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: The merge from hell...

From
Junio C Hamano <junkio@cox.net>
Date
Feb 2, 2006, 07:05 UTC
Message-ID
<7v8xsuuto5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.64.0602012212200.21884@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
Show 5 quoted lines
>  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? ;-)

Show 5 quoted lines
> 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!
Previous: Linus TorvaldsNext: Junio C Hamano
Message 2 of 40 in “The merge from hell...”
  1. Linus TorvaldsFeb 2, 2006
  2. Junio C HamanoFeb 2, 2006
  3. combine-diff: reuse diff from the same blob.Junio C Hamano, Feb 2, 2006
  4. Linus TorvaldsFeb 2, 2006
  5. Linus TorvaldsFeb 2, 2006
  6. Linus TorvaldsFeb 2, 2006
  7. combine-diff: update --cc "uninteresting hunks" logic.Junio C Hamano, Feb 2, 2006
  8. combine-diff: add safety check to --cc.Junio C Hamano, Feb 2, 2006
  9. Linus TorvaldsFeb 2, 2006
  10. Junio C HamanoFeb 3, 2006
  11. Linus TorvaldsFeb 3, 2006
  12. [Attn - repository browser authors] diff-tree combined format.Junio C Hamano, Feb 3, 2006
  13. Marco CostalbaFeb 3, 2006
  14. Junio C HamanoFeb 3, 2006
  15. Junio C HamanoFeb 3, 2006
  16. Marco CostalbaFeb 4, 2006
  17. Paul MackerrasFeb 4, 2006
  18. Junio C HamanoFeb 3, 2006
  19. Paul MackerrasFeb 4, 2006
  20. Junio C HamanoFeb 4, 2006
  21. Paul MackerrasFeb 4, 2006
  22. Junio C HamanoFeb 4, 2006
  23. Linus TorvaldsFeb 4, 2006
  24. Linus TorvaldsFeb 4, 2006
  25. Marco CostalbaFeb 2, 2006
  26. Linus TorvaldsFeb 2, 2006
  27. Aneesh KumarFeb 2, 2006
  28. Junio C HamanoFeb 2, 2006
  29. Linus TorvaldsFeb 2, 2006
  30. Junio C HamanoFeb 2, 2006
  31. Linus TorvaldsFeb 5, 2006
  32. Add a "git show" command to show a commitLinus Torvalds, Feb 5, 2006
  33. Fix git-rev-parse over-eager errorsLinus Torvalds, Feb 5, 2006
  34. Junio C HamanoFeb 5, 2006
  35. Linus TorvaldsFeb 5, 2006
  36. Junio C HamanoFeb 6, 2006
  37. Junio C HamanoFeb 5, 2006
  38. Linus TorvaldsFeb 5, 2006
  39. Linus TorvaldsFeb 5, 2006
  40. Junio C HamanoFeb 6, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.