# Re: [RFC] Two conceptually distinct commit commands 5 messages from 2006-12-05 to 2006-12-05. Participants: Horst H. von Brand, Carl Worth, Jakub Narebski. Thread: https://gitlist.dev/t/43589 ## Horst H. von Brand, 2006-12-05 00:52 Subject: Re: [RFC] Two conceptually distinct commit commands Message-ID: <200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612050052.kB50qcn2026534%40laptop13.inf.utfsm.cl In-Reply-To: ``` Carl Worth wrote: [...] > Proposal > ------- > Here are the two commit commands I would like to see in git: > > commit-index-content [paths...] > > Commits the content of the index for the given paths, (or all > paths in the index). The index content can be manipulated with > "git add", "git rm", "git mv", and "git update-index". > > commit-working-tree-content [paths...] > > 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 Edit somefile, utterly changing it: Get backup called somefile~ mv somefile newfile commit-working-tree-contents: somefile~ saved, newfile lost Edit somefile a bit, move it to newfile. Make sure no backups left over. commit-working-tree-contents: somefile deleted, newfile lost 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). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 ``` ## Carl Worth, 2006-12-05 01:18 Subject: Re: [RFC] Two conceptually distinct commit commands Message-ID: <87zma316oc.wl%cworth@cworth.org> URL: https://gitlist.dev/e/87zma316oc.wl%25cworth%40cworth.org In-Reply-To: <200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl> ``` 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 ``` ## Jakub Narebski, 2006-12-05 01:19 Subject: Re: [RFC] Two conceptually distinct commit commands Message-ID: URL: https://gitlist.dev/e/el2hbm%24oi0%241%40sea.gmane.org In-Reply-To: <200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl> ``` Horst H. von Brand wrote: > Carl Worth wrote: > > [...] > >> Proposal >> ------- >> Here are the two commit commands I would like to see in git: >> >> commit-index-content [paths...] >> >> Commits the content of the index for the given paths, (or all >> paths in the index). The index content can be manipulated with >> "git add", "git rm", "git mv", and "git update-index". >> >> commit-working-tree-content [paths...] >> >> 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 No, you don't, assuming that you have *~ in .gitignore or .git/info/exclude > Edit somefile, utterly changing it: Get backup called somefile~ > mv somefile newfile > commit-working-tree-contents: somefile~ saved, newfile lost No, assuming that you use git-mv as you should. > Edit somefile a bit, move it to newfile. Make sure no backups left over. > commit-working-tree-contents: somefile deleted, newfile lost No, as above. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Horst H. von Brand, 2006-12-05 02:14 Subject: Re: [RFC] Two conceptually distinct commit commands Message-ID: <200612050214.kB52E7mG027926@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612050214.kB52E7mG027926%40laptop13.inf.utfsm.cl In-Reply-To: ``` Carl Worth wrote: > 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. How do you distinguish a "new file, same contents as old file" from "old file, renamed"? What is the difference between: mv somefile newfile and cp somefine newfile rm somefile ? How should cp somefile newfile vi somefile be handled? How about cp somefile oldfile vi somefile or just mv somefile oldfile ? Or cp somefile somefile.my-own-bakup vi somefile ? The whole problem is your description based on "file renaming" and such. AFAIU git has a list of file names it is tracking, and for those names it keeps track of what the contents for each are at each commit. That the name somefile had some contents that later show up as newfile (both names tracked) is recorded just as that. You could /interpret/ this as a "rename" if somefile is then gone, but it could well be something else. Besides, you'd have to search for the old somefile contents among /all/ newfiles just to find out it was renamed. Better don't mix facts with interpretation (== guesses on what operations came in between the snapshots git takes). Note that it should never matter what strange ideas a random user gets for naming her temporary backup files, or their git configuration. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 ``` ## Carl Worth, 2006-12-05 02:32 Subject: Re: [RFC] Two conceptually distinct commit commands Message-ID: <87y7pn138y.wl%cworth@cworth.org> URL: https://gitlist.dev/e/87y7pn138y.wl%25cworth%40cworth.org In-Reply-To: <200612050214.kB52E7mG027926@laptop13.inf.utfsm.cl> ``` On Mon, 04 Dec 2006 23:14:07 -0300, "Horst H. von Brand" wrote: > What is the difference between: > mv somefile newfile > and > cp somefine newfile > rm somefile There is no difference. This is git, a content tracker. Same for the rest. > The whole problem is your description based on "file renaming" and > such. OK. Strike the words "or rename" from the description, leaving just: Any removal of a tracked file will be detected and committed automatically. The rest of my analysis still stands, I believe. And I'd be glad to accept further suggestions on documenting these. The goal is simply to have a user-oriented description of the semantics that are consistent between the current "git commit -a" and "git commit files..." commands. -Carl ```