Re: feature suggestion: optimize common parts for checkout --conflict=diff3

On Wed, Mar 06, 2013 at 01:50:46PM -0800, Junio C Hamano wrote:

I think that is only the case sometimes. It depends on what is in the conflict, and what your data is. I think you are conflating two things, though: zealousness of merge, and having the original content handy when resolving. To me, diff3 is about the latter. It can also be a hint that the user cares about the former, but not necessarily.

Because for the lines that _are_ changed, you may want to see what the original looked like. Here's a more realistic example:

	git init repo
	cd repo

	# Some baseline C code.
	cat >foo.c <<\EOF
	int foo(int bar)
	{
	  return bar + 5;
	}
	EOF
	git add foo.c
	git commit -m base
	git tag base

	# Simulate a modification to the function.
	sed -i '2a\
	  if (bar < 3)\
	    bar *= 2;
	' foo.c
	git commit -am multiply
	git tag multiply

	# And another modification.
	sed -i 's/bar + 5/bar + 7/' foo.c
	git commit -am plus7

	# Now on a side branch...
	git checkout -b side base

	# let's cherry pick the first change. Obviously
	# we could just fast-forward in this toy example,
	# but let's try to simulate a real history.
	#
	# We insert a sleep so that the cherry-pick does not
	# accidentally end up with the exact same commit-id (again,
	# because this is a toy example).
	sleep 1
	git cherry-pick multiply

	# and now let's make a change that conflicts with later
	# changes on master
	sed -i 's/bar + 5/bar + 8/' foo.c
	git commit -am plus8

	# and now merge, getting a conflict
	git merge master

	# show the result with various marker styles
	for i in merge diff3 zdiff3; do
	  echo
	  echo "==> $i"
	  git.compile checkout --conflict=$i foo.c
	  cat foo.c
	done

which produces:

	==> merge
	int foo(int bar)
	{
	  if (bar < 3)
	    bar *= 2;
	<<<<<<< ours
	  return bar + 8;
	=======
	  return bar + 7;
	>>>>>>> theirs
	}

The ZEALOUS level has helpfully cut out the shared cherry-picked bits, and let us focus on the real change.

	==> diff3
	int foo(int bar)
	{
	<<<<<<< ours
	  if (bar < 3)
	    bar *= 2;
	  return bar + 8;
	||||||| base
	  return bar + 5;
	=======
	  if (bar < 3)
	    bar *= 2;
	  return bar + 7;
	>>>>>>> theirs
	}

Here we get to see all of the change, but the interesting difference is overwhelmed by the shared cherry-picked bits. It's only 2 lines here, but of course it could be much larger in a real example, and the reader is forced to manually verify that the early parts are byte-for-byte identical.

	==> zdiff3
	int foo(int bar)
	{
	  if (bar < 3)
	    bar *= 2;
	<<<<<<< ours
	  return bar + 8;
	||||||| base
	  return bar + 5;
	=======
	  return bar + 7;
	>>>>>>> theirs
	}

Here we see the hunk cut-down again, removing the cherry-picked parts. But the presence of the base is still interesting, because we see something that was not in the "merge" marker: that we were originally at "5", and moved to "7" on one side and "8" on the other.

I see conflicts like this when I rebase my topics forward; you may pick up part of my series, or even make a tweak to a patch in the middle. I prefer diff3 markers because they carry more information (and use them automatically via merge.conflictstyle). But in some cases, the lack of zealous reduction means that I end having to figure out whether and if anything changed in the seemingly identical bits. Sometimes it is nothing, and sometimes you tweaked whitespace or fixed a typo, and it takes a lot of manual looking to figure it out. I hadn't realized it was related to the use of diff3 until the discussion today.

-Peff