From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.176.0/21 X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 From: Carl Worth Subject: Re: [RFC] Two conceptually distinct commit commands Date: Mon, 04 Dec 2006 12:10:18 -0800 Message-ID: <87bqmj2zit.wl%cworth@cworth.org> References: <87d56z32e1.wl%cworth@cworth.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Dec__4_12:10:12_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Mon, 4 Dec 2006 20:11:35 +0000 (UTC) Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: <87d56z32e1.wl%cworth@cworth.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Received: from vger.kernel.org ([209.132.176.167]) by dough.gmane.org with esmtp (Exim 4.50) id 1GrK9n-0005Aw-AG for gcvg-git@gmane.org; Mon, 04 Dec 2006 21:11:19 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937357AbWLDUK7 (ORCPT ); Mon, 4 Dec 2006 15:10:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S937360AbWLDUK7 (ORCPT ); Mon, 4 Dec 2006 15:10:59 -0500 Received: from cworth.org ([217.160.249.188]:55896 "EHLO theworths.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S937357AbWLDUK5 (ORCPT ); Mon, 4 Dec 2006 15:10:57 -0500 Received: (qmail 18415 invoked from network); 4 Dec 2006 15:10:56 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 4 Dec 2006 15:10:56 -0500 To: git@vger.kernel.org Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Mon_Dec__4_12:10:12_2006-1 Content-Type: text/plain; charset=US-ASCII > So, if I could do: > > git apply --index > git commit-index-content > git commit-index-content > > Then this would do exactly what I want. I wouldn't even have > to think about whether my local modifications are to any of > the same paths as touched by the patch. BTW, the current "apply --index" doesn't allow what I imagined in the scenario above. It notices that the affected file is different in the working tree compared to the index and just refuses to do anything. Given that safety-valve in git-apply, the current behavior of "git commit paths" would allow for splitting a submitted patch into two commits. The difference is that it only works if the local modifications do not affect any of the same paths as the patch. The user is freed from worrying about this somewhat, since if it's not the case, then git-apply just complains and doesn't do anything. But what might be very interesting is a modified "git-apply --index" that would not fail in this case, but would instead do the following: 1. Apply the patch to the working tree 2. Apply the patch to the index And of course, if either fails then the entire apply operation fails, leaving no changes to working tree or to the index. With that new git-apply behavior, then the scenario I outlined above would work, and would work in spite of any changes to the same file in both the working tree and the index. It would also require the separate commands for commit-index-content vs. commit-working-tree-content as described in my original message above. -Carl --pgp-sign-Multipart_Mon_Dec__4_12:10:12_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFdICq6JDdNq8qSWgRAhW5AJ9SIf6p7/+OdBtIHSmQdueJ0SiMPgCeK+HC jRm9thCc3WmLrm00F00OKQs= =7Tpz -----END PGP SIGNATURE-----