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

merge-base: fully contaminate the well.

From
Junio C Hamano <junkio@cox.net>
Date
Nov 11, 2005, 02:58 UTC
Message-ID
<7vzmobuc00.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.64.0511091348530.4627@g5.osdl.org>

The discussion on the list demonstrated a pathological case where an ancestor of a merge-base can be left interesting. This commit introduces a postprocessing phase to fix it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
  Linus Torvalds <torvalds@osdl.org> writes:
  > On Wed, 9 Nov 2005, Junio C Hamano wrote:
  >
  >> But the point of well-poisoning you did in merge-base was to
  >> detect that E is an ancestor of B and exclude it in the first
  >> place.
  >
  > Ahh, you're right, and I'm wrong. That "E" is not a real merge-base, since 
  > there _is_ a valid merge-base that is a direct descendant of it and thus 
  > objectively better.
  >
  > Which means that sometimes it can stop with too _many_ merge heads, just 
  > because it hasn't realized that they are reachable through a chain that is 
  > otherwise provably uninteresting.
  I am not particularly proud of this change, but here is an
  attempt to fully contaminate the well without going all the
  way down to root.  It adds a postprocessing phase which does
  not parse any new commits.
  > The thing is, I don't see what guarantees that the show-branch brhaviour 
  > is safe or conservative.
  You are right about this; I have a separate patch to fix it.
 merge-base.c |   78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

applies-to: 8eacf17303188e55375f76bea8051555ba1baf02 a2fd94f707128f3f390362725c8d8b0802940111

diff --git a/merge-base.c b/merge-base.c
index 286bf0e..43a6818 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -80,6 +80,45 @@ static struct commit *interesting(struct
  * Now, list does not have any interesting commit.  So we find the newest
  * commit from the result list that is not marked uninteresting.  Which is
  * commit B.
+ *
+ *
+ * Another pathological example how this thing can fail to mark an ancestor
+ * of a merge base as UNINTERESTING without the postprocessing phase.
+ *
+ *		  2
+ *		  H
+ *	    1    / \
+ *	    G   A   \
+ *	    |\ /     \ 
+ *	    | B       \
+ *	    |  \       \
+ *	     \  C       F
+ *	      \  \     / 
+ *	       \  D   /   
+ *		\ |  /
+ *		 \| /
+ *		  E
+ *
+ *	 list			A B C D E F G H
+ *	 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
+ *	 B1 A2			2 1 - - 3 2 1 2
+ *	 C1 A2			2 1 1 - 3 2 1 2
+ *	 D1 A2			2 1 1 1 3 2 1 2
+ *	 A2			2 1 1 1 3 2 1 2
+ *	 B3			2 3 1 1 3 2 1 2
+ *	 C7			2 3 7 1 3 2 1 2
+ *
+ * At this point, unfortunately, everybody in the list is
+ * uninteresting, so we fail to complete the following two
+ * steps to fully marking uninteresting commits.
+ *
+ *	 D7			2 3 7 7 3 2 1 2
+ *	 E7			2 3 7 7 7 2 1 2
+ *
+ * and we end up showing E as an interesting merge base.
  */
 
 static int show_all = 0;
@@ -88,6 +127,7 @@ static int merge_base(struct commit *rev
 {
 	struct commit_list *list = NULL;
 	struct commit_list *result = NULL;
+	struct commit_list *tmp = NULL;
 
 	if (rev1 == rev2) {
 		printf("%s\n", sha1_to_hex(rev1->object.sha1));
@@ -104,9 +144,10 @@ static int merge_base(struct commit *rev
 
 	while (interesting(list)) {
 		struct commit *commit = list->item;
-		struct commit_list *tmp = list, *parents;
+		struct commit_list *parents;
 		int flags = commit->object.flags & 7;
 
+		tmp = list;
 		list = list->next;
 		free(tmp);
 		if (flags == 3) {
@@ -130,6 +171,41 @@ static int merge_base(struct commit *rev
 	if (!result)
 		return 1;
 
+	/*
+	 * Postprocess to fully contaminate the well.
+	 */
+	for (tmp = result; tmp; tmp = tmp->next) {
+		struct commit *c = tmp->item;
+		/* Reinject uninteresting ones to list,
+		 * so we can scan their parents.
+		 */
+		if (c->object.flags & UNINTERESTING)
+			commit_list_insert(c, &list);
+	}
+	while (list) {
+		struct commit *c = list->item;
+		struct commit_list *parents;
+
+		tmp = list;
+		list = list->next;
+		free(tmp);
+
+		/* Anything taken out of the list is uninteresting, so
+		 * mark all its parents uninteresting.  We do not
+		 * parse new ones (we already parsed all the relevant
+		 * ones).
+		 */
+		parents = c->parents;
+		while (parents) {
+			struct commit *p = parents->item;
+			parents = parents->next;
+			if (!(p->object.flags & UNINTERESTING)) {
+				p->object.flags |= UNINTERESTING;
+				commit_list_insert(p, &list);
+			}
+		}
+	}
+
 	while (result) {
 		struct commit *commit = result->item;
 		result = result->next;
---
0.99.9.GIT
Previous: Linus TorvaldsNext: Linus Torvalds
Message 31 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.