Re: [RFC/PATCH] Add git-unresolve <paths>...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Carl Worth <cworth@xxxxxxxxxx> writes:

> But this does introduce an unfortunate semantic clash with the
> existing git-resolve, (which is an automated merge tool of some sort).
> I don't know much about the existing git-resolve, but a recent thread
> suggests it is a non-useful relic and people shouldn't be using it.

It is useful in a quick-and-dirty way, but does the same thing
as 'git merge -s resolve' and that is why people discussed
about removing it.  It has semantics quite different from
update-index, so I'd ignore the synonym part of your
discussion.

Time for a quick raise-hand.  Does anybody still use 'git
resolve'?  Maybe we could remove it by 1.4?

> It would be nice if the complementary operations of manually
> resolving and unresolving a merge conflict had complementary command
> names.

True.  I considered two other possibilities.

 * "git unmerge", because it creates unmerged index entries, and

 * "git update-index --unmerge", because this is just a special
   kind of updates to the index file.

> ... For example, it might also complain if it notices
> conflict markers in the file. That seems like it would be a useful
> convenience.

Since you should compile test the merge result before going
anywhere, and the primary target of git is to manage sources, it
might not matter in most of the case, but for non-sources and non
compiled languages, that certainly is an issue.

When it _does_ matter, you can have a customized pre-commit hook
to look for the conflict markers, like this:

diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 43d3b6e..723a9ef 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -61,6 +61,9 @@ perl -e '
 	    if (/^\s* 	/) {
 		bad_line("indent SP followed by a TAB", $_);
 	    }
+	    if (/^(?:[<>=]){7}/) {
+		bad_line("unresolved merge conflict", $_);
+	    }
 	}
     }
     exit($found_bad);

As usual, you can defeat the check with "git commit --no-verify"
for unlikely false matches.

> That's not much guidance for a new user that perhaps is only used to
> "git commit -a" and "git pull" that usually works. Without getting too
> verbose, this might be improved with something like:
>
> 	Automatic merge failed; fix conflicts by hand, then commit the result

That should be an easy patch ;-).

diff --git a/git-merge.sh b/git-merge.sh
index 78ab422..b834e79 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -335,5 +335,5 @@ Conflicts:
 	then
 		git-rerere
 	fi
-	die "Automatic merge failed; fix up by hand"
+	die "Automatic merge failed; fix conflicts and then commit the result."
 fi

-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]