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 17:01:39 -0700 Message-ID: <87slo92jz0.wl%cworth@cworth.org> References: <7vu08p72sn.fsf@assigned-by-dhcp.cox.net> <87acah6zk6.wl%cworth@cworth.org> <7v8xq16y31.fsf@assigned-by-dhcp.cox.net> <87wtdl2o5o.wl%cworth@cworth.org> <7vk69l5gi1.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_17:01:33_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 Thu Apr 20 02:04:49 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 1FWMfA-0001CD-8l for gcvg-git@gmane.org; Thu, 20 Apr 2006 02:04:48 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751330AbWDTAEp (ORCPT ); Wed, 19 Apr 2006 20:04:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751338AbWDTAEp (ORCPT ); Wed, 19 Apr 2006 20:04:45 -0400 Received: from cworth.org ([217.160.249.188]:31970 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1751330AbWDTAEo (ORCPT ); Wed, 19 Apr 2006 20:04:44 -0400 Received: (qmail 31383 invoked from network); 19 Apr 2006 20:04:43 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 19 Apr 2006 20:04:43 -0400 To: Junio C Hamano In-Reply-To: <7vk69l5gi1.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_17:01:33_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 19 Apr 2006 15:48:22 -0700, Junio C Hamano wrote: > Carl Worth writes: > > > Meanwhile, I still think it's worth re-considering the original > > problem. > > Maybe you are misunderstanding something in a major way,... It's possible, but it's also possible I'm just failing to express myself clearly. > > After a failed merge, I get a multi-parent diff from "git > > diff". However, after updating the index, I can't find any way to get > > multi-parent diffs anymore. > > ... and that is exactly what this "unmerge to re-populate higher > order stages" does. The multi-parent diff you have been looking > at failed merge _is_ generated by comparing the higher order > stages and your working tree file. But unmerging puts my index back into a not-ready-to-commit state, right? If so, then that's what I don't like from this proposal. > > I'd still like to be able to do that, even when I know that what I > > have in the index is good, and I don't want to undo it. > > You cannot it have both ways. Either you want to have the unmerged > entries (so that you *can* view the combined diff), or you do > not want to have them (then you obviously cannot view the > combined diff between the working tree file and these stages). I don't understand. Why would the entire diff operation have to happen inside the index? As soon as I'm done with the merge commit I can do "git show" and see a multi-parent diff. That doesn't have to muck with my index, does it? By, example, (using the merge from the git tutorial), just before updating the index I get a lovely multi-parent diff: $ git diff diff --cc hello index 06fa6a2,cc44c73..0000000 --- a/hello +++ b/hello @@@ -1,3 -1,3 +1,4 @@@ Hello World It's a new day for git +Play, play, play + Work, work, work then I can update the index: $ git update-index hello and at this point I know I can see a single-parent diff before committing: $ git diff --cached diff --git a/hello b/hello index 06fa6a2..8798bdc 100644 --- a/hello +++ b/hello @@ -1,3 +1,4 @@ Hello World It's a new day for git Play, play, play +Work, work, work But what I want to do instead is at this point get the multi-parent diff. Finally, after I commit, it's easy to get multi-parent diff again: $ git commit -m "Resolved merge conflict" $ PAGER= git show commit 547599946cf5dfb04af804e9d5451beb17662dca Merge: 35e0e9b... 698ac13... Author: Carl Worth Date: Wed Apr 19 16:51:55 2006 -0700 Resolved merge conflict diff --cc hello index 06fa6a2,cc44c73..8798bdc --- a/hello +++ b/hello @@@ -1,3 -1,3 +1,4 @@@ Hello World It's a new day for git +Play, play, play + Work, work, work So why can't I get that same result before committing without changing my index? If the answer is that current implementation doesn't provide for that, (that is, it provides either an in-index multi-diff for files in multiple stages, OR it provides a multi-parent diff for a multi-parent commit object), then that's fine. But that doesn't seem like any fundamental limitation preventing what I'd like to have. Am I making more sense now? Or am I still missing something? -Carl --pgp-sign-Multipart_Wed_Apr_19_17:01:33_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBERs9j6JDdNq8qSWgRAlRCAJ9t0Ad/+DXjBl5iiuPIlXu0z9URGQCfZ6NM Z6KKnep2tGS1osDSMyXgucA= =0Egk -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Apr_19_17:01:33_2006-1--