From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: [FAQ?] Rationale for git's way to manage the index Date: Wed, 09 May 2007 09:29:00 -0700 Message-ID: <873b26klkj.wl%cworth@cworth.org> References: <46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com> <20070509134151.GT4489@pasky.or.cz> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_May__9_09:29:00_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Petr Baudis , Martin Langhoff , git@vger.kernel.org To: Linus Torvalds X-From: git-owner@vger.kernel.org Wed May 09 18:29:30 2007 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hlp2g-0002Jr-7Q for gcvg-git@gmane.org; Wed, 09 May 2007 18:29:30 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758115AbXEIQ3S (ORCPT ); Wed, 9 May 2007 12:29:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756288AbXEIQ3R (ORCPT ); Wed, 9 May 2007 12:29:17 -0400 Received: from theworths.org ([217.160.253.102]:59406 "EHLO theworths.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757987AbXEIQ3Q (ORCPT ); Wed, 9 May 2007 12:29:16 -0400 Received: (qmail 18771 invoked from network); 9 May 2007 12:29:00 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 9 May 2007 12:29:00 -0400 In-Reply-To: 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_May__9_09:29:00_2007-1 Content-Type: text/plain; charset=US-ASCII On Wed, 9 May 2007 08:52:09 -0700 (PDT), Linus Torvalds wrote: [Snip good description of rebuilding a branch to meet some "target" state.] That's all really good stuff. And as you mentioned you sometimes use cherry-pick during this rebuilding, one can also use "git add -i" to help with splitting up an ugly commit that should have been multiple commit. For example, a sequence might look like this, (I always use "desired" where you use target): git diff HEAD desired | git apply git add -i git commit git reset --hard # test here and commit --amend as needed And repeat that as needed. It's really no different than your "edit the diff" approach. It's just using "add -i" instead of a text editor. But I do admit that the commit;reset;test;--amend sequence might seem a bit too awkward to some people. > test-things, but since one of them was a filesystem fix, and the other one > was in the kernel, rather than give all the paths explicitly, I'd do > > git commit fs/ > > and it will automatically do the right thing (actually, I often end up > using the two-stage "git add" + "git commit" thing, because one of the > more common cases for me is that I'm going to commit a merge that I fixed > up a conflict in, and then you have to do it that way). This reminds me of a confusing semantic issue that came about with the "new" add. It can be quite natural to commit a single file in one step with: git commit some-file.c or to do that in two steps with: git add some-file.c git commit (which is particularly useful if one wants to add multiple files). I recently found myself wanting to do a similar thing with a directory path. I can commit a path with: git commit path/ but I don't get anything at all like the same semantics if I do: git add path/ git commit (since "git add" will recursively add all untracked files under path/). Now the "recursively add all files" behavior is older, and has been an essential part of git-add forever. But I found it to be not at all what I wanted in this case, (where I'm now trained to say "git add" to stage things into the index). I don't know of any good fix for the problem now. Maybe I'll just need to remember to break out that old "git update-index" for a situation like this, but that sure feels clunky. -Carl --pgp-sign-Multipart_Wed_May__9_09:29:00_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGQfbM6JDdNq8qSWgRAhmZAKCoFTGRNg+cxOE+t2CZRhAqSfz2EwCgntBM 59Ay5GTqjSwJy4urJ/BBzRA= =lnFo -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_May__9_09:29:00_2007-1--