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 <junkio@xxxxxxx> Message-ID: <7vfyatt8di.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> 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 <paths>..." --- 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 <paths>..." 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
Attachment:
pgpLGF60656IS.pgp
Description: PGP signature