From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: [RFC/PATCH] Add git-unresolve ... Date: Wed, 19 Apr 2006 14:11:21 -0700 Message-ID: <87acah6zk6.wl%cworth@cworth.org> References: <7vu08p72sn.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Apr_19_14:11:21_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Wed Apr 19 23:14:33 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FWK0L-0005JV-SP for gcvg-git@gmane.org; Wed, 19 Apr 2006 23:14:30 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751230AbWDSVO0 (ORCPT ); Wed, 19 Apr 2006 17:14:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751243AbWDSVO0 (ORCPT ); Wed, 19 Apr 2006 17:14:26 -0400 Received: from cworth.org ([217.160.249.188]:25566 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1751230AbWDSVO0 (ORCPT ); Wed, 19 Apr 2006 17:14:26 -0400 Received: (qmail 20905 invoked from network); 19 Apr 2006 17:14:25 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 19 Apr 2006 17:14:25 -0400 To: Junio C Hamano In-Reply-To: <7vu08p72sn.fsf@assigned-by-dhcp.cox.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Wed_Apr_19_14:11:21_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 19 Apr 2006 13:01:28 -0700, Junio C Hamano wrote: > > This is an attempt to address the issue raised on #git channel > recently by Carl Worth. ... > With git-unresolve ..., the versions from our branch and > their branch for specified blobs are placed in stage #2 and > stage #3, without touching the working tree files. This gives > you the combined diff back for easier review, along with > "diff --ours" and "diff --theirs". Thanks. This looks quite interesting. The name of git-unresolve seems reasonable on its own. In fact, git-merge already uses "resolve" to describe manual conflict resolution. For example: echo "Using the $best_strategy to prepare resolving by hand." 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 would be nice if the complementary operations of manually resolving and unresolving a merge conflict had complementary command names. Would it be feasible to cop-opt the git-resolve name as a synonym for update-index? (I certainly wouldn't mind a shorter name for that operation.) In fact, git-resolve could even go beyond being a synonym for update-index. For example, it might also complain if it notices conflict markers in the file. That seems like it would be a useful convenience, (and no functionality would be robbed, since update-index would still be available for anyone who needs to commit content that looks like conflict markers). Another thing I've been meaning to suggest soon is better output for when an automatic merge fails. Currently, the final message is: Automatic merge failed; fix up by hand 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 In addition, if git-commit is run with unmerged files, it could also provide some extra guidance. Perhaps something like this, (just after the list of "needs merge" files mentioned by git-update-index): Fix any conflicts in these files, then git-resolve each and commit again -Carl --pgp-sign-Multipart_Wed_Apr_19_14:11:21_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBERqd56JDdNq8qSWgRAsgGAJ44DOk2HAHs1Xl4exzzvNW7SUN4cACdG/W3 nDE3fdgWZ6VSCDq3iqbB8ww= =jZ9K -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Apr_19_14:11:21_2006-1--