From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: Separating "add path to index" from "update content in index" Date: Fri, 22 Dec 2006 08:55:08 -0800 Message-ID: <87ac1fj2fn.wl%cworth@cworth.org> References: <89b129c60612191233s5a7f36f2hd409c4b9a2bbbc5c@mail.gmail.com> <7v64c7pmlw.fsf@assigned-by-dhcp.cox.net> <87wt4m2o99.wl%cworth@cworth.org> <7vmz5i6vqb.fsf@assigned-by-dhcp.cox.net> <87vek62n1k.wl%cworth@cworth.org> <7v1wmu5ecs.fsf@assigned-by-dhcp.cox.net> <87tzzp3fgh.wl%cworth@cworth.org> <7vbqlw92fw.fsf@assigned-by-dhcp.cox.net> <87d56cirs8.wl%cworth@cworth.org> <7vfyb87bxg.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_Fri_Dec_22_08:55:08_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Peter Baumann , git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Dec 22 17:57:48 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by dough.gmane.org with esmtp (Exim 4.50) id 1GxniK-00067d-59 for gcvg-git@gmane.org; Fri, 22 Dec 2006 17:57:44 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751056AbWLVQ4h (ORCPT ); Fri, 22 Dec 2006 11:56:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751070AbWLVQ4h (ORCPT ); Fri, 22 Dec 2006 11:56:37 -0500 Received: from cworth.org ([217.160.249.188]:48871 "EHLO theworths.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751021AbWLVQ4g (ORCPT ); Fri, 22 Dec 2006 11:56:36 -0500 Received: (qmail 15317 invoked from network); 22 Dec 2006 11:56:34 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 22 Dec 2006 11:56:34 -0500 To: Junio C Hamano In-Reply-To: <7vfyb87bxg.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_Fri_Dec_22_08:55:08_2006-1 Content-Type: text/plain; charset=US-ASCII On Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote: > Running diff with index is what I do almost all the time. Yes, me too. As I said, months ago I had complained about "git diff" meaning diff from index. But I was wrong. It really is the right thing > And it is not just limited to adding the contents of a path that > happened to be told git for the first time. Adding the contents > of a path that was known to git also happens only when it is in > a presentable good state. So running "git diff" and not seeing > what I added before is a GOOD THING. Yes. Whenever consciously using the index, being able to stash stuff there and not see it in "git diff" is definitely a good thing. After a thread not so long ago, someone told me privately that they really wished they could see more examples of when using the index is obviously a net win to the user. He mentioned that the oft-cited "split commit along file boundaries" isn't compelling since the same behavior can be achieved with "commit file1 file2". So here's another example that I was using just yesterday: I implemented an optimization and started testing it. It had the performance characteristics I wanted, but also introduced a couple few regressions noticed by the test suite. So this code wasn't ready to commit, but I stashed it all into the index. Then I went through an iterative process of fixing the little regressions (off-by-one bugs, etc.), using "git diff" to see _only_ the incremental fix, and then stashing the whole result into the index again. Then I only committed once all the regressions were fixed. Note that in the above scenario, the command I've been proposing recently, ("update the index with the content of all tracked files"), would have been quite useful. Also note that with "git commit --amend" one could get a very similar result by simply using the HEAD commit as the staging area instead of the index. (And with reflogs, some might like that even better.) So yes, "git diff" showing the difference from the index is definitely the right thing. And it's useful whenever I'm consciously using the index to stash some content, (as in this example), or when git does that on my behalf (as in a conflicted merge). My point is that I'm not always interested in stashing content just because I want to add a new path to the index. For example, let's say I sit down with my working tree and I just want to remember what I had been in the middle of doing. I examine the state of things with "git diff". It doesn't show me the content of any newly-created files, but I want to see those as well. So I'd love to be able to easily get the index into a state where "git diff" shows me that content. And I'm definitely not ready to stash the content of these new files---I haven't even looked at them yet---that's what I'd like "git diff" to help me do at this point. Anyway, you already said you did understand this mode of operation. So I won't explain it over and over anymore. I really just wanted to throw out that index-staging example for people. -Carl --pgp-sign-Multipart_Fri_Dec_22_08:55:08_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFjA3s6JDdNq8qSWgRAjTWAJ9v3UHUc4OxiCkjrdF4MlMWDyFA3ACaAgxV rn5iUd9RfBHONjB2ybUYl24= =dTgH -----END PGP SIGNATURE----- --pgp-sign-Multipart_Fri_Dec_22_08:55:08_2006-1--