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 22:38:20 -0800 Message-ID: <87r6ve26g3.wl%cworth@cworth.org> References: <87d56z32e1.wl%cworth@cworth.org> <20061205035123.GA8831@thunk.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Dec__4_22:38:20_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Tue, 5 Dec 2006 06:39:11 +0000 (UTC) Cc: git@vger.kernel.org Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: <20061205035123.GA8831@thunk.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 1GrTxJ-0000Bn-EA for gcvg-git@gmane.org; Tue, 05 Dec 2006 07:39:05 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936886AbWLEGjA (ORCPT ); Tue, 5 Dec 2006 01:39:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S937187AbWLEGjA (ORCPT ); Tue, 5 Dec 2006 01:39:00 -0500 Received: from cworth.org ([217.160.249.188]:59623 "EHLO theworths.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S936886AbWLEGjA (ORCPT ); Tue, 5 Dec 2006 01:39:00 -0500 Received: (qmail 20407 invoked from network); 5 Dec 2006 01:38:58 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 5 Dec 2006 01:38:58 -0500 To: Theodore Tso Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Mon_Dec__4_22:38:20_2006-1 Content-Type: text/plain; charset=US-ASCII On Mon, 4 Dec 2006 22:51:23 -0500, Theodore Tso wrote: > > If adds aren't going done automatically (because otherwise you have > problems with foo.c~ accidentally getting checked it), then it's > non-symmetric to expect that deletes will also happen automatically. > It's relatively rare that files are removed or renamed, and sometimes > files accidentally disappear. It's non-symmetric, yes, but it's what I would personally like. It's not an essential aspect of the proposal, so it could go either way as the git crowd decides. To explain my personal preference, I like the notion of all files being "untracked" until I inform the system about their existence. After that, I'd like the system to take care of them and notice when they get modified, or when they get deleted. > So in the case where there are no pathnames given to "git > commit-working-tree-content", I would argue that it does not do any > implicit "git add" on new files NOR any implicit "git rm" on missing > files unless the user actually specifies an --implicit-add or > --implicit-delete option, respectively. If users want to make > --implicit-add and/or --implicit-delete the default, that could be a > configuration option, but I don't think it should be a default. The ability to configure --implicit-delete and --implicit-add to git-commit seems good. They're long enough arguments that > What should happen to foo.c in the index? Should it be stay the same? > Should the contents be replaced with version of foo.c that has just > been commited? The latter seems to make sense, but runs the risk of > losing the data (what was in the index). The former has the downside > that the index might have a version of foo.c which is older than what > has been just commited, which could be confusing. Or should git > commit-working-tree abort with an error message if index != HEAD? This case is already under debate in a separate thread. There "git commit files", (which really is commit-working-tree-content already), currently errors out in this case, but the proposal is to allow it to proceed with the commit, (thereby "losing" the intermediate staged content). -Carl --pgp-sign-Multipart_Mon_Dec__4_22:38:20_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFdRPc6JDdNq8qSWgRAp64AKCTuUQKNsoskuvptKIL0M/h7w8HMwCfZPLB CtfrNJddOPr+YMY15Ds4IiI= =zsJc -----END PGP SIGNATURE-----