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

Re: Comments on recursive merge..

From
Junio C Hamano <junkio@cox.net>
Date
Nov 9, 2005, 20:13 UTC
Message-ID
<7virv1efzv.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.64.0511090800330.3247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> That "extra" check only helps once. If we ever hit the "extra--", it's 
> gone.

I think you are right here, but while digging into this I found an interesting case.

The current show-branch code does the same as merge-base in the pathological example depicted in merge-base.c, but they seem to do different things to this picture (commit grows from bottom to top, time flows alphabetically; find base between G and H).

                 H
                / \
           G   A   \
           |\ /     \ 
           | B       \
           |  \       \
            \  C       F
             \  \     / 
              \  D   /   
               \ |  /
                \| /
		 E

"git-merge-base --all" says the merge bases are B and E, while "show-branch --merge-base" mentions only B. In this case the latter is probably the better answer. Actually git-merge-base without --all only mentions E. This is because we give up when we find the list elements are all uninteresting. And this is very expensive to fix (I recall mentioning "horizon effect" last time we worked on this --- around August 12th).

G gets bit 1 and H gets bit 2. Here is what happens in each iteration:

	List			A B C D E F G H		Result
	G1 H2			- - - - - - 1 2
	H2 E1 B1		- 1 - - 1 - 1 2
	F2 E1 B1 A2		2 1 - - 1 2 1 2
	E3 B1 A2		2 1 - - 3 2 1 2		E3
	B1 A2			2 1 - - 3 2 1 2		E3
	C1 A2			2 1 1 - 3 2 1 2		E3
	D1 A2			2 1 1 1 3 2 1 2		E3
	A2			2 1 1 1 3 2 1 2		E3
	B3			2 3 1 1 3 2 1 2		E3 B3
	C7			2 3 7 1 3 2 1 2		E3 B3

We popped B with flag 3, and started contaminating the well by reinjecting its parent C with flag 7. That is all good, but "while (interesting(list))" check stops us from going further. Ideally the following two steps would have found out that E is also uninteresting.

	D7			2 3 7 7 3 2 1 2
	E7			2 3 7 7 7 2 1 2
But that is expensive -- we would not know when to stop.

A reproduction recipe is attached here, primarily so I do not have to worry about losing it from /var/tmp/.

-- >8 -- cut here -- >8 -- #!/bin/sh

rm -fr .git && git-init-db T=$(git-write-tree)

M=1130000000 Z=+0000

export GIT_COMMITTER_EMAIL=git@comm.iter.xz export GIT_COMMITTER_NAME='C O Mmiter' export GIT_AUTHOR_NAME='A U Thor' export GIT_AUTHOR_EMAIL=git@au.thor.xz

doit() {
	OFFSET=$1; shift
	NAME=$1; shift
	PARENTS=
	for P
	do
		PARENTS="${PARENTS}-p $P "
	done
	GIT_COMMITTER_DATE="$(($M + $OFFSET)) $Z"
	GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE
	export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
	commit=$(echo $NAME | git-commit-tree $T $PARENTS)
	echo $commit >.git/refs/tags/$NAME
	echo $commit
}
checkit() {
    echo MB
    git-merge-base --all "$@" | xargs git-name-rev
    echo SB
    git-show-branch --merge-base "$@" | xargs git-name-rev
    git-show-branch --sha1-name --more=99 "$@"
}

E=$(doit 5 E) D=$(doit 4 D $E) F=$(doit 6 F $E) C=$(doit 3 C $D) B=$(doit 2 B $C) A=$(doit 1 A $B) G=$(doit 7 G $B $E) H=$(doit 8 H $A $F)

checkit $G $H
exit
Previous: Linus TorvaldsNext: Linus Torvalds
Message 27 of 58 in “Comments on recursive merge..”
  1. Linus TorvaldsNov 7, 2005
  2. Linus TorvaldsNov 7, 2005
  3. merge-recursive: Only print relevant rename messagesFredrik Kuivinen, Nov 7, 2005
  4. Junio C HamanoNov 7, 2005
  5. Fredrik KuivinenNov 9, 2005
  6. Fredrik KuivinenNov 7, 2005
  7. Junio C HamanoNov 8, 2005
  8. Linus TorvaldsNov 8, 2005
  9. Junio C HamanoNov 8, 2005
  10. Johannes SchindelinNov 8, 2005
  11. Fredrik KuivinenNov 8, 2005
  12. Junio C HamanoNov 8, 2005
  13. Linus TorvaldsNov 8, 2005
  14. Fredrik KuivinenNov 8, 2005
  15. Linus TorvaldsNov 8, 2005
  16. Johannes SchindelinNov 8, 2005
  17. Linus TorvaldsNov 9, 2005
  18. Junio C HamanoNov 9, 2005
  19. Petr BaudisNov 9, 2005
  20. Linus TorvaldsNov 9, 2005
  21. Junio C HamanoNov 9, 2005
  22. Linus TorvaldsNov 9, 2005
  23. Junio C HamanoNov 9, 2005
  24. Junio C HamanoNov 9, 2005
  25. Petr BaudisNov 9, 2005
  26. Linus TorvaldsNov 9, 2005
  27. Junio C HamanoNov 9, 2005
  28. Linus TorvaldsNov 9, 2005
  29. Junio C HamanoNov 9, 2005
  30. Linus TorvaldsNov 9, 2005
  31. merge-base: fully contaminate the well.Junio C Hamano, Nov 11, 2005
  32. Linus TorvaldsNov 11, 2005
  33. Junio C HamanoNov 11, 2005
  34. Linus TorvaldsNov 11, 2005
  35. Junio C HamanoNov 11, 2005
  36. Johannes SchindelinNov 8, 2005
  37. Make git-recursive the default strategy for git-pull.Junio C Hamano, Nov 8, 2005
  38. Junio C HamanoNov 11, 2005
  39. Linus TorvaldsNov 11, 2005
  40. Junio C HamanoNov 12, 2005
  41. Ryan AndersonNov 12, 2005
  42. GIT commit statistics.Junio C Hamano, Nov 12, 2005
  43. Martin LanghoffNov 12, 2005
  44. Petr BaudisNov 12, 2005
  45. Catalin MarinasNov 15, 2005
  46. Chuck LeverNov 15, 2005
  47. Johannes SchindelinNov 12, 2005
  48. Junio C HamanoNov 13, 2005
  49. Martin LanghoffNov 13, 2005
  50. Junio C HamanoNov 14, 2005
  51. Martin LanghoffNov 14, 2005
  52. Junio C HamanoNov 14, 2005
  53. Martin LanghoffNov 14, 2005
  54. Petr BaudisNov 14, 2005
  55. Martin LanghoffNov 14, 2005
  56. Junio C HamanoNov 14, 2005
  57. Junio C HamanoNov 15, 2005
  58. Petr BaudisNov 13, 2005

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.