On Mon, 04 Dec 2006 21:52:38 -0300, "Horst H. von Brand" wrote: > > Commits the content of the working tree for the given paths, (or > > all tracked paths). Untracked files can be committed for the first > > time by specifying their names on the command-line or by using > > "git add" to add them just prior to the commit. Any rename or > > removal of a tracked file will be detected and committed > > automatically. > > Edit somefile with, e.g, emacs: Get backup called somefile~ > Realize that somefile is nonsense, delete it(s edited version) > commit-working-tree-contents: Now you have the undesirable somefile~ saved The semantics I intended to describe for commit-working-tree-content would not add this file. That's a "new file" so would have to be mentioned either explicitly on the command-line or in a git-add command before it would be committed. > Edit somefile, utterly changing it: Get backup called somefile~ > mv somefile newfile > commit-working-tree-contents: somefile~ saved, newfile lost OK, you've found a bug in my description above, (though not in the intended semantics). By "rename...detected automatically" I meant only that the fact that a file has "disappeared" as part of a rename need not be mentioned to git. The fact that the contents are made available as a new file name still would need to be told to git with "git add", (or would be worthwhile to mention "git mv" I suppose). > This is /not/ easy to get right, as it depends on what the user wants, and > the random programs run in between git commands. > > You need to tell git somehow what files you want saved, and which ones are > junk. I.e., just the first command (unfortunately). Perhaps I was too oblique in calling this thing commit-working-tree-contents. This isn't some fabricated-from-scratch command. The intent of my message was that readers would recognize the description as matching what the current "commit -a" and "commit files..." commands do. So I really wasn't trying to invent anything really different than those. So almost any problems of unexpected behavior you can find almost surely apply to "commit -a" already. I did throw one new thing into the description, (that does not exist in current git). That's the mention that new files could be added by mentioning them explicitly on the command-line. This was intended as a way to allow a tutorial to sidestep the details of how "git add" interacts with the index. If this one feature is a bad idea, it could be dropped with no impact on the rest of the proposal nor my discussion of it. Similarly, I worded the mention of "git add" to suggest it be done "just prior to the commit". Again, I did this just to avoid having to mention anything about the need to "git add" again if the file was edited between the time of add and the time of commit. That language is already proposed for the git-add documentation, so there's no need to repeat it all here. -Carl
Attachment:
pgpDZtDYt0cjX.pgp
Description: PGP signature