Segfault on merge with 1.6.2.1

Greetings.

I'm trying to figure out what's going on with a merge I'm trying to do. As  
far as I know, it's a fairly standard situation, just merging two  
branches. But I get a segfault each time. This occurs with 1.5.6.5 and  
1.6.2.1. The earlier version is on a Debian Etch box with  
backports.debian.org. The latter is Debian Sid. I also tried on a Windows  
box with MSysGit 1.6.2.1-preview20090322.exe.

The 1.6.2.1 version just segfaults, but 1.5.6.5 says:

/usr/bin/git-merge: line 438: 32335 Segmentation fault       
git-merge-$strategy $common -- "$head_arg" "$@"
Merge with strategy recursive failed.

In all cases, .git/index.lock is left behind.

I'm using the default configuration, with only a few basic options in my  
person .gitconfig.

Unfortunately, I cannot post the archive, but I can tar the archive and  
share that with individuals, if need be.

The problems started with a weird merge by another developer a while ago  
that somehow reapplied earlier commits. It looked like he had done some  
commits that wiped some earlier commits but then a commit or two latter  
the old commits were added back. When I tried to merge the resulting  
master into my working branch it segfaulted. I didn't have time (or the  
immediate need) to look into it then and it's been forgotten until now  
(when, of course, it needs to be done in the next few days :( ).

I have run git gc and also pruned a couple of minor dangling objects.  
Running git fsck --full reveals no problems. The largest file is about  
6MiB.

I've asked on #git, and drizzd there suggested I try here. At this point  
I'm completely at a loss.

Any help would be greatly appreciated.

Thanks,
Michael

-- 
Michael D Johnson   [off-list ref]    
redbeardcreator.deviantart.com

"Marketing research...[has] shown that energy weapons that make sounds sell
  better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)

On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson [off-list ref] wrote:

The 1.6.2.1 version just segfaults, but 1.5.6.5 says:

/usr/bin/git-merge: line 438: 32335 Segmentation fault       
git-merge-$strategy $common -- "$head_arg" "$@"
Merge with strategy recursive failed.

In all cases, .git/index.lock is left behind.

That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
directly without a fork. Could you try it in gdb and provide a
backtrace, please?

On Sun, 29 Mar 2009 07:17:00 -0500, Miklos Vajna [off-list ref]  
wrote:

On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson  
[off-list ref] wrote:

quoted

The 1.6.2.1 version just segfaults, but 1.5.6.5 says:

/usr/bin/git-merge: line 438: 32335 Segmentation fault
git-merge-$strategy $common -- "$head_arg" "$@"
Merge with strategy recursive failed.

In all cases, .git/index.lock is left behind.

That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
directly without a fork. Could you try it in gdb and provide a
backtrace, please?

Well, I've got a backtrace, but I don't have debugging symbols,  
apparently. There is not a Debian package I can find that has them. I  
checked debug.debian.net, as well as the standard sid repository. So I  
will have to rebuild the package with debugging turned on. I will not be  
able to do that tonight, unfortunately. I will probably have a chance  
tomorrow evening.

Just in case it might be useful, though, here's the backtrace, without  
symbols.

Starting program: /usr/bin/git merge origin/dojo-1.3
(no debugging symbols found)
... repeated multiple times ...
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
... repeated multiple times
[New Thread 0xb7a73b30 (LWP 21505)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a73b30 (LWP 21505)]
0x080e5a6f in ?? ()
(gdb) backtrace
#0  0x080e5a6f in ?? ()
#1  0x0893e000 in ?? ()
#2  0x000f0000 in ?? ()
#3  0xbf949098 in ?? ()
#4  0x080e63ad in ?? ()
#5  0x08977fcf in ?? ()
#6  0x000f0000 in ?? ()
#7  0xfff0ffff in ?? ()
#8  0x08945dd8 in ?? ()
#9  0x00000000 in ?? ()

Thanks for the continuing help.

Michael

-- 
Michael D Johnson   [off-list ref]    
redbeardcreator.deviantart.com

"Marketing research...[has] shown that energy weapons that make sounds sell
  better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)

Hi,

On Sun, 29 Mar 2009, Michael Johnson wrote:

On Sun, 29 Mar 2009 07:17:00 -0500, Miklos Vajna [off-list ref]
wrote:

quoted

On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson
[off-list ref] wrote:

quoted

The 1.6.2.1 version just segfaults, but 1.5.6.5 says:

/usr/bin/git-merge: line 438: 32335 Segmentation fault
git-merge-$strategy $common -- "$head_arg" "$@"
Merge with strategy recursive failed.

In all cases, .git/index.lock is left behind.

That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
directly without a fork. Could you try it in gdb and provide a
backtrace, please?

Well, I've got a backtrace, but I don't have debugging symbols, apparently.
There is not a Debian package I can find that has them. I checked
debug.debian.net, as well as the standard sid repository. So I will have to
rebuild the package with debugging turned on. I will not be able to do that
tonight, unfortunately. I will probably have a chance tomorrow evening.

Just in case it might be useful, though, here's the backtrace, without
symbols.

Starting program: /usr/bin/git merge origin/dojo-1.3
(no debugging symbols found)
... repeated multiple times ...
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
... repeated multiple times
[New Thread 0xb7a73b30 (LWP 21505)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a73b30 (LWP 21505)]
0x080e5a6f in ?? ()
(gdb) backtrace
#0  0x080e5a6f in ?? ()
#1  0x0893e000 in ?? ()
#2  0x000f0000 in ?? ()
#3  0xbf949098 in ?? ()
#4  0x080e63ad in ?? ()
#5  0x08977fcf in ?? ()
#6  0x000f0000 in ?? ()
#7  0xfff0ffff in ?? ()
#8  0x08945dd8 in ?? ()
#9  0x00000000 in ?? ()

This segfault sounds vaguely like something I tried to fix.  
Unfortunately, I cannot spend time on it right now, except send you the 
patch that could help the issue:

-- snipsnap --

From 084909acbb576be4c4815e047ee4247b95c70cda Mon Sep 17 00:00:00 2001

From: Johannes Schindelin <redacted>
Date: Mon, 10 Nov 2008 23:25:31 +0100
Subject: [PATCH] merge-recursive: fail gracefully with directory/submodule conflicts

Signed-off-by: Johannes Schindelin <redacted>
---
 merge-recursive.c         |   15 ++++++++-------

diff --git a/merge-recursive.c b/merge-recursive.c
index 3e1bc3e..8ada5a9 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c

@@ -519,14 +519,14 @@ static void update_file_flags(struct merge_options *o,
 		void *buf;
 		unsigned long size;
 
-		if (S_ISGITLINK(mode))
-			die("cannot read object %s '%s': It is a submodule!",
-			    sha1_to_hex(sha), path);
-
-		buf = read_sha1_file(sha, &type, &size);
+		if (S_ISGITLINK(mode)) {
+			buf = xstrdup(sha1_to_hex(sha));
+			size = strlen(buf);
+		} else
+			buf = read_sha1_file(sha, &type, &size);
 		if (!buf)
 			die("cannot read object %s '%s'", sha1_to_hex(sha), path);
-		if (type != OBJ_BLOB)
+		if (!S_ISGITLINK(mode) && type != OBJ_BLOB)
 			die("blob expected for %s '%s'", sha1_to_hex(sha), path);
 		if (S_ISREG(mode)) {
 			struct strbuf strbuf = STRBUF_INIT;

@@ -542,7 +542,8 @@ static void update_file_flags(struct merge_options *o,
 			free(buf);
 			goto update_index;
 		}
-		if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) {
+		if (S_ISGITLINK(mode) || S_ISREG(mode) ||
+				(!has_symlinks && S_ISLNK(mode))) {
 			int fd;
 			if (mode & 0100)
 				mode = 0777;

On Sun, Mar 29, 2009 at 09:39:49PM -0500, Michael Johnson [off-list ref] wrote:

Well, I've got a backtrace, but I don't have debugging symbols,  
apparently. There is not a Debian package I can find that has them. I  
checked debug.debian.net, as well as the standard sid repository. So I  
will have to rebuild the package with debugging turned on. I will not be  
able to do that tonight, unfortunately. I will probably have a chance  
tomorrow evening.

Okay, no rush. In case Dscho's patch does not fix your problem, please
rebuild git with debug symbols enabled and send a normal trace.

Thanks.

On Mon, 30 Mar 2009 06:03:35 -0500, Miklos Vajna [off-list ref]  
wrote:

On Sun, Mar 29, 2009 at 09:39:49PM -0500, Michael Johnson  
[off-list ref] wrote:

quoted

Well, I've got a backtrace, but I don't have debugging symbols,
apparently. There is not a Debian package I can find that has them. I
checked debug.debian.net, as well as the standard sid repository. So I
will have to rebuild the package with debugging turned on. I will not be
able to do that tonight, unfortunately. I will probably have a chance
tomorrow evening.

Okay, no rush. In case Dscho's patch does not fix your problem, please
rebuild git with debug symbols enabled and send a normal trace.

It would appear that the patch has already been applied to 1.6.2.1.

That said, here's my backtrace. I've tried tracing through to figure out  
where the problem is occurring, but my gdb-foo is non-existent, I'm wating  
for some GUIs to install, and I'm ready for some sleep :| So if I haven't  
heard back by tomorrow evening, I'll be running one of the frontends for  
gdb until I have something traced down :)

If you need any more information, please let me know.

Thanks,
Michael

(gdb) run merge origin/dojo-1.3
Starting program: /usr/bin/git merge origin/dojo-1.3
[Thread debugging using libthread_db enabled]
[New Thread 0xb7b1bb30 (LWP 2651)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b1bb30 (LWP 2651)]
0x080fa828 in parse_tree (item=0x0) at tree.c:250
250		if (item->object.parsed)
(gdb) backtrace
#0  0x080fa828 in parse_tree (item=0x0) at tree.c:250
#1  0x080cc40b in init_tree_desc_from_tree (desc=0xbfdf53ac, tree=0x0) at  
merge-recursive.c:161
#2  0x080cc4d4 in git_merge_trees (index_only=1, common=0x8fa5df8,  
head=0x0, merge=0x8fa5718) at merge-recursive.c:186
#3  0x080cf28e in merge_trees (o=0xbfdf54d0, head=0x0, merge=0x8fa5718,  
common=0x8fa5df8, result=0xbfdf5448)
     at merge-recursive.c:1170
#4  0x080cf75f in merge_recursive (o=0xbfdf54d0, h1=0x8ffc200,  
h2=0x8f992f0, ca=0x0, result=0xbfdf548c)
     at merge-recursive.c:1294
#5  0x080cf6c7 in merge_recursive (o=0xbfdf54d0, h1=0x8f99050,  
h2=0x8f98ff0, ca=0x8f97b98, result=0xbfdf551c)
     at merge-recursive.c:1280
#6  0x08080d75 in try_merge_strategy (strategy=0x811b9b0 "recursive",  
common=0x8fd40f0, head_arg=0x811be14 "HEAD")
     at builtin-merge.c:566
#7  0x08082446 in cmd_merge (argc=1, argv=0xbfdf5808, prefix=0x0) at  
builtin-merge.c:1111
#8  0x0804bb5f in run_builtin (p=0x8130400, argc=2, argv=0xbfdf5808) at  
git.c:244
#9  0x0804bcf3 in handle_internal_command (argc=2, argv=0xbfdf5808) at  
git.c:388
#10 0x0804bdf0 in run_argv (argcp=0xbfdf5780, argv=0xbfdf5784) at git.c:434
#11 0x0804bf82 in main (argc=2, argv=0xbfdf5808) at git.c:505

-- 
Michael D Johnson   [off-list ref]    
redbeardcreator.deviantart.com

"Marketing research...[has] shown that energy weapons that make sounds sell
  better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)

On Tue, 31 Mar 2009 02:14:21 -0500, Michael Johnson  
[off-list ref] wrote:

That said, here's my backtrace. I've tried tracing through to figure out  
where the problem is occurring, but my gdb-foo is non-existent, I'm  
wating for some GUIs to install, and I'm ready for some sleep :| So if I  
haven't heard back by tomorrow evening, I'll be running one of the  
frontends for gdb until I have something traced down :)

I tried tracing it manually with KDbg tonight. But either I'm too tired  
(and my patience is low), or I'm just not capable of understanding it. I  
hope it's the former, since I was able to follow the basic flow well  
enough. But I still wasn't terribly happy with the front end. It's obvious  
that gdb is awesome, I'm just not ready for it yet :)

Anyway, I decided to try an experiment, as I had mentioned to someone that  
if I couldn't get this bug tracked down, I'd have to do the merge  
manually. So... I figured out the common ancestor (I used git show-branch,  
but I'm betting there's an easier way), and merged the ancestor + 1 of the  
other branch into my HEAD. It segfaulted. So, I tried the resolve strategy  
at the same point. Amazingly, it worked. And a default recursive merge  
handled the rest.

That means my current problem is resolved, but I'm guessing a segfault on  
a default merge is still a bad thing, so I'll try to keep up on this. I do  
have a copy of the repository before the merge (several, right now,  
actually), so I can try fixes. If I'm lucky I'll have some time to work on  
it myself. But it will be at least two weeks before I actually have the  
time to personally track down the problem without help. However, I should  
be able to assist someone else fairly easily.

In short, I don't personally need a fix right now, but I can help figure  
out what is broken with it.

Thanks,
Michael

-- 
Michael D Johnson   [off-list ref]    
redbeardcreator.deviantart.com

"Marketing research...[has] shown that energy weapons that make sounds sell
  better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)

On Wed, Apr 01, 2009 at 12:43:38AM -0500, Michael Johnson [off-list ref] wrote:

Anyway, I decided to try an experiment, as I had mentioned to someone that  
if I couldn't get this bug tracked down, I'd have to do the merge  
manually. So... I figured out the common ancestor (I used git show-branch,  
but I'm betting there's an easier way), and merged the ancestor + 1 of the  
other branch into my HEAD. It segfaulted. So, I tried the resolve strategy  
at the same point. Amazingly, it worked. And a default recursive merge  
handled the rest.

I initially replied to this thread as I wasn't sure if it's a bug in
merge-recursive or builtin-merge itself. I'm not that familiar with
merge-recursive, that's why I didn't reply so far. ;-)

In short, I don't personally need a fix right now, but I can help figure  
out what is broken with it.

If you don't need rename detection, you can merge with '-s resolve', I
think that would do what you need and it avoids the problematic
codepath.

On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote:

It would appear that the patch has already been applied to 1.6.2.1.

I don't think it has. But judging from the stack trace this bug is unrelated
to the patch anyways.

If nobody else is dealing with this I'd like to have a look at it. Could you
please send me a copy of the repo.

Thanks,
Clemens

On Wed, 01 Apr 2009 13:06:27 -0500, Clemens Buchacher [off-list ref]  
wrote:

On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote:

quoted

It would appear that the patch has already been applied to 1.6.2.1.

I don't think it has. But judging from the stack trace this bug is  
unrelated to the patch anyways.

When I tried to appy the patch I got a conflict (I applied it directly to  
Debian's source package for git-core). When I compared the code to the  
patch it appeared it had been applied. Of course, I'm far from an expert  
at applying patches, so I might have misread the direction of the patch.

If nobody else is dealing with this I'd like to have a look at it. Could  
you please send me a copy of the repo.

It doesn't sound like anyone else is. So I'll send you a copy shortly, off  
list.

Thanks for all the help,
Michael

-- 
Michael D Johnson   [off-list ref]    
redbeardcreator.deviantart.com

"Marketing research...[has] shown that energy weapons that make sounds sell
  better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)

Signed-off-by: Clemens Buchacher <redacted>
---
 t/t7405-submodule-merge.sh |   74 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100755 t/t7405-submodule-merge.sh

diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
new file mode 100755
index 0000000..9778ad4
--- /dev/null
+++ b/t/t7405-submodule-merge.sh

@@ -0,0 +1,74 @@
+#!/bin/sh
+
+test_description='merging with submodules'
+
+. ./test-lib.sh
+
+#
+# history
+#
+#        a --- c
+#      /   \ /
+# root      X
+#      \   / \
+#        b --- d
+#
+
+test_expect_success setup '
+
+	mkdir sub &&
+	(cd sub &&
+	 git init &&
+	 echo original > file &&
+	 git add file &&
+	 test_tick &&
+	 git commit -m sub-root) &&
+	git add sub &&
+	test_tick &&
+	git commit -m root &&
+
+	git checkout -b a master &&
+	(cd sub &&
+	 echo A > file &&
+	 git add file &&
+	 test_tick &&
+	 git commit -m sub-a) &&
+	git add sub &&
+	test_tick &&
+	git commit -m a &&
+
+	git checkout -b b master &&
+	(cd sub &&
+	 echo B > file &&
+	 git add file &&
+	 test_tick &&
+	 git commit -m sub-b) &&
+	git add sub &&
+	test_tick &&
+	git commit -m b
+
+	git checkout -b c a &&
+	git merge -s ours b &&
+
+	git checkout -b d b &&
+	git merge -s ours a
+'
+
+test_expect_failure 'merging with modify/modify conflict' '
+
+	git checkout -b test1 a &&
+	test_must_fail git merge b &&
+	test -f .git/MERGE_MSG &&
+	git diff
+
+'
+
+test_expect_failure 'merging with a modify/modify conflict between merge bases' '
+
+	git reset --hard HEAD &&
+	git checkout -b test2 c &&
+	git merge d
+
+'
+
+test_done

-- 
1.6.2.1

This simplifies the code without changing the semantics and removes
the unhelpful "needs $sha1" part of the conflicting submodule message.

Signed-off-by: Clemens Buchacher <redacted>
---
 merge-recursive.c |   17 ++++-------------
 1 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index f1b120b..d6f0582 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c

@@ -1116,22 +1116,13 @@ static int process_entry(struct merge_options *o,
 				 o->branch1, o->branch2);
 
 		clean_merge = mfi.clean;
-		if (mfi.clean)
-			update_file(o, 1, mfi.sha, mfi.mode, path);
-		else if (S_ISGITLINK(mfi.mode)) {
-			output(o, 1, "CONFLICT (submodule): Merge conflict in %s "
-			       "- needs %s", path, sha1_to_hex(b.sha1));
-			update_file(o, 0, mfi.sha, mfi.mode, path);
-		} else {
+		if (!mfi.clean) {
+			if (S_ISGITLINK(mfi.mode))
+				reason = "submodule";
 			output(o, 1, "CONFLICT (%s): Merge conflict in %s",
 					reason, path);
-
-			if (o->call_depth)
-				update_file(o, 0, mfi.sha, mfi.mode, path);
-			else
-				update_file_flags(o, mfi.sha, mfi.mode, path,
-					      0 /* update_cache */, 1 /* update_working_directory */);
 		}
+		update_file(o, mfi.clean, mfi.sha, mfi.mode, path);
 	} else if (!o_sha && !a_sha && !b_sha) {
 		/*
 		 * this entry was deleted altogether. a_mode == 0 means

-- 
1.6.2.1

When merging merge bases during a recursive merge we do not want to
leave any unmerged entries. Otherwise we cannot create a temporary
tree for the recursive merge to work with.

We failed to do so in case of a submodule conflict between merge
bases, causing a NULL pointer dereference in the next step of the
recursive merge.

Signed-off-by: Clemens Buchacher <redacted>
---
 merge-recursive.c          |    5 +++--
 t/t7405-submodule-merge.sh |    2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 3e1bc3e..f1b120b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c

@@ -1118,10 +1118,11 @@ static int process_entry(struct merge_options *o,
 		clean_merge = mfi.clean;
 		if (mfi.clean)
 			update_file(o, 1, mfi.sha, mfi.mode, path);
-		else if (S_ISGITLINK(mfi.mode))
+		else if (S_ISGITLINK(mfi.mode)) {
 			output(o, 1, "CONFLICT (submodule): Merge conflict in %s "
 			       "- needs %s", path, sha1_to_hex(b.sha1));
-		else {
+			update_file(o, 0, mfi.sha, mfi.mode, path);
+		} else {
 			output(o, 1, "CONFLICT (%s): Merge conflict in %s",
 					reason, path);
 

diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
index 9778ad4..aa6c44c 100755
--- a/t/t7405-submodule-merge.sh
+++ b/t/t7405-submodule-merge.sh

@@ -63,7 +63,7 @@ test_expect_failure 'merging with modify/modify conflict' '
 
 '
 
-test_expect_failure 'merging with a modify/modify conflict between merge bases' '
+test_expect_success 'merging with a modify/modify conflict between merge bases' '
 
 	git reset --hard HEAD &&
 	git checkout -b test2 c &&

-- 
1.6.2.1

Hi,

The segmentation fault is caused by a null pointer dereference which happens
during recursive merge with a submodule conflict between two merge bases. This
is fixed by the following patches.

However, there are other problems with merging submodules. For example, git
diff aborts with "fatal: read error 'sub'" for conflicting submodules. I have
also added a test for this.

Dscho has already started working on related issues. I have therefore skipped
t7404, which is already used in Dscho's work.

Clemens

 merge-recursive.c          |   16 ++-------
 t/t7405-submodule-merge.sh |   74 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+), 12 deletions(-)

[PATCH 1/3] add tests for merging with submodules
[PATCH 2/3] update cache for conflicting submodule entries
[PATCH 3/3] simplify output of conflicting merge

Will queue, forking from maint.  Thanks.

Hi,

On Sun, 5 Apr 2009, Clemens Buchacher wrote:

The segmentation fault is caused by a null pointer dereference which 
happens during recursive merge with a submodule conflict between two 
merge bases. This is fixed by the following patches.

However, there are other problems with merging submodules. For example, 
git diff aborts with "fatal: read error 'sub'" for conflicting 
submodules. I have also added a test for this.

Dscho has already started working on related issues. I have therefore 
skipped t7404, which is already used in Dscho's work.

Thanks for working on this,
Dscho

On Sat, 04 Apr 2009 19:46:57 -0500, Clemens Buchacher [off-list ref]  
wrote:

The segmentation fault is caused by a null pointer dereference which  
happens during recursive merge with a submodule conflict between two
merge bases. This is fixed by the following patches.

Amazingly I follow that. And the tracing I was doing now makes sense. I  
saw the null pointer dereference, but couldn't figure out why. The  
submodule conflict explains some things about what was going on in the  
tree.

+# history
+#
+#        a --- c
+#      /   \ /
+# root      X
+#      \   / \
+#        b --- d

This also explains a lot. Is there any way to get this sort of simplified  
representation from the existing tools? I would think gitk would show it,  
but would I be able to recognize it.?

However, there are other problems with merging submodules. For example,  
git diff aborts with "fatal: read error 'sub'" for conflicting  
submodules.
I have also added a test for this.

I believe there's a GSoC proposal that would help with this... from what I  
read of it, it could prove very helpful to my workflow.

Anyway, thanks for all the help. I'll merge the patches in locally and see  
if they work for me when I get a bit of time. I'm sure they will... it's  
just for my own peace of mind.

Thanks again,
Michael

-- 
Michael D Johnson   [off-list ref]    
redbeardcreator.deviantart.com

"Marketing research...[has] shown that energy weapons that make sounds sell
  better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)

On Sun, Apr 05, 2009 at 09:29:33PM -0500, Michael Johnson wrote:

quoted

+# history
+#
+#        a --- c
+#      /   \ /
+# root      X
+#      \   / \
+#        b --- d

This also explains a lot. Is there any way to get this sort of simplified 
representation from the existing tools? I would think gitk would show it, 
but would I be able to recognize it.?

I simply tagged everything that showed up in "git merge-base --all" and then
I did "gitk --all --simplify-by-decoration". That shows pretty much the
graph above.