From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: [PATCH] git-status: wording update to deal with deleted files. Date: Thu, 11 Jan 2007 17:28:37 -0800 Message-ID: <878xg9xcca.wl%cworth@cworth.org> References: <87bql5cok3.fsf@morpheus.local> <7vejq12nlu.fsf@assigned-by-dhcp.cox.net> <7vsleh16ey.fsf_-_@assigned-by-dhcp.cox.net> <87ac0pxgl2.wl%cworth@cworth.org> <7v1wm114rx.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_Thu_Jan_11_17:28:31_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Jan 12 02:30:53 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 1H5BFn-0001GB-Lu for gcvg-git@gmane.org; Fri, 12 Jan 2007 02:30:48 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932608AbXALBad (ORCPT ); Thu, 11 Jan 2007 20:30:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932640AbXALBad (ORCPT ); Thu, 11 Jan 2007 20:30:33 -0500 Received: from mx1.redhat.com ([66.187.233.31]:48644 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932608AbXALBac (ORCPT ); Thu, 11 Jan 2007 20:30:32 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0C1UUhL022256; Thu, 11 Jan 2007 20:30:30 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0C1UU56030650; Thu, 11 Jan 2007 20:30:30 -0500 Received: from raht.cworth.org (sebastian-int.corp.redhat.com [172.16.52.221]) by mail.boston.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0C1UToL003682; Thu, 11 Jan 2007 20:30:29 -0500 To: Junio C Hamano In-Reply-To: <7v1wm114rx.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_Thu_Jan_11_17:28:31_2007-1 Content-Type: text/plain; charset=US-ASCII On Thu, 11 Jan 2007 16:13:06 -0800, Junio C Hamano wrote: > You are twisting my words ;-). I apologize. I really didn't intend to twist any words. What I was remembering was a sentence like the following: From: Junio C Hamano Message-ID: <7vfyatt8di.fsf@assigned-by-dhcp.cox.net> Subject: Re: How to commit removed file? Date: Tue, 02 Jan 2007 13:40:41 -0800 ... Personally I never saw the point of having "git rm". Maybe we should remove it to prevent this confusion from happening. What I'll describe below would actually allow us to drop git-rm if we really wanted to, (but I don't think it's important to do that, nor that we even should). That's just an almost accidental side effect of what I'm describing. > But that is not the only workflow we encourage. > > I do encourage "commit -a" or "commit after update-index" and > frown upon but tolerate "commit ..." --- all of the above > is in line with this world view. OK, so let's use these two different workflows and look at what we're providing. (Personally, I also like to think about only two different workflows, but I see "commit ..." as just doing a file-boundary-based subset of "commit -a"). Currently, the necessary, porcelain, "commit preparing" commands for each workflow are: commit after update-index ------------------------- git add: add content for new files, modified files git rm: mark files to be removed commit -a --------- git add: mark new files to be committed > Then the issue is how to expose update-index to the end users. > "add" is about adding the content. What's unfortunate is that > adding a file as zero-length content is still different from > removing it. But fortunately the distinction between a zero-length file that exists and a file that does not exist is quite evident in the working tree. So it would still be a very well-defined thing to have a command for "update content" that could update whatever content a file has into the index (even zero-length content) if the file exists in the working tree, or remove the path from the index if the file does not exist. I agree that "add" would be an insane name for this command. The best proposal I've been able to make for this command is "stage". The only other thing I can think of that uses accepted terminology from git would be "update", but I think that would be a very bad choice, (since certain other version control systems use "update" to describe an operation much more like git's "pull"). So if we had this "stage" command, (and assuming it staged content for new files), then look what happens to the list of preparatory commands needed for each workflow: commit after stage ------------------ git stage: stage content for new, modified, or removed files commit -a --------- git add: mark new files to be committed Compare that to the above description. Isn't it beautiful from a conceptual point-of-view? The "git rm" command isn't needed at all, (though we could certainly still provide it). And now the "git add" command only has one conceptual use, for (of all thing!) adding new files, not updating content for files that have been modified. > Honestly, removing is so different from the norm that I do not > see major inconsistency nor inconvenience, practically nor in > philosophy, to have two separate Porcelain-ish commands, add and > rm, to perform content additions and removal. I don't have a problem with it either. I'm not trying to make an argument based on why git-rm should be removed. It can live around all it wants, but I think there's conceptual simplification in this model, (which can only help to make git easier to learn). -Carl --pgp-sign-Multipart_Thu_Jan_11_17:28:31_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFpuRF6JDdNq8qSWgRAlzRAJ0eJ5hWskk6b0WdrOuRdEG/+XCCAACeOLxC Kl33GD+zVeEGI/zWCmstzz4= =ED0q -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan_11_17:28:31_2007-1--