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:14:48 -0700 Message-ID: <87r73t2jd3.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> <7vmzeh3ypu.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:14:48_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:18:06 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 1FWMrw-00038G-Dn for gcvg-git@gmane.org; Thu, 20 Apr 2006 02:18:00 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751256AbWDTARy (ORCPT ); Wed, 19 Apr 2006 20:17:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751338AbWDTARy (ORCPT ); Wed, 19 Apr 2006 20:17:54 -0400 Received: from cworth.org ([217.160.249.188]:51938 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1751256AbWDTARx (ORCPT ); Wed, 19 Apr 2006 20:17:53 -0400 Received: (qmail 32209 invoked from network); 19 Apr 2006 20:17:53 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 19 Apr 2006 20:17:53 -0400 To: Junio C Hamano In-Reply-To: <7vmzeh3ypu.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:14:48_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 19 Apr 2006 16:57:49 -0700, Junio C Hamano wrote: > > I suspect this is just a misunderstanding caused by insufficient > explanation, so let's try this a bit differently. Junio, Thanks for the careful explanation. > With the patch applied (or use "next" branch I'll be pushing out > shortly), let's try the core-tutorial example up to the point > where we need to make a merge commit and get conflict. Heh. We dropped back to the identical example with our crossed-in-flight messages. > But later (much later) we find out that there was something > wrong with this hand-resolve and now we would want to fix it. > The new command, "git unresolve" is designed to help us exactly > in this situation: Yes. And this was in fact the question I had asked in IRC. How to get the diff again when I realize the file I updated is wrong. And as you point out, git-unresolve does just the trick here. The question I asked in my latest message is basically just "Shouldn't there be a way to get the diff from the several parents to the index?". That's slightly different, but it is the functionality I was looking for when I was trying to recover from my update-of-botched-merge. And its useful separately as part of the pre-commit-review I've said I always want to be able to do, (and as you designed "git status -v" to provide). So there's the final piece I'd like here. I think "git status -a -v" should provide a multi-parent diff when merging, as should "git status -v" after manually doing an update-index while merging. -Carl --pgp-sign-Multipart_Wed_Apr_19_17:14:48_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBERtJ46JDdNq8qSWgRArbAAJ9R3d8kksmmDFxaMIUYn48PJs8McgCgjAg8 wiWSpnn1BPJhtfy3nbkVOro= =Smg1 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Apr_19_17:14:48_2006-1--