{"thread":{"id":"43589","subject":"Re: [RFC] Two conceptually distinct commit commands","startedAt":"2006-12-05T00:52:38Z","lastAt":"2006-12-05T02:32:45Z","messageCount":5,"participants":["Horst H. von Brand","Carl Worth","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295739","messageId":"200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl","threadId":"43589","inReplyTo":"cworth@cworth.org","subject":"Re: [RFC] Two conceptually distinct commit commands","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-05T00:52:38Z","receivedAt":"2006-12-05T00:52:38Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Carl Worth wrote:\n\n[...]\n\n> Proposal\n> -------\n> Here are the two commit commands I would like to see in git:\n> \n> commit-index-content [paths...]\n> \n> Commits the content of the index for the given paths, (or all\n> paths in the index). The index content can be manipulated with\n> \"git add\", \"git rm\", \"git mv\", and \"git update-index\".\n> \n> commit-working-tree-content [paths...]\n> \n> Commits the content of the working tree for the given paths, (or\n> all tracked paths). Untracked files can be committed for the first\n> time by specifying their names on the command-line or by using\n> \"git add\" to add them just prior to the commit. Any rename or\n> removal of a tracked file will be detected and committed\n> automatically.\n\nEdit somefile with, e.g, emacs: Get backup called somefile~\nRealize that somefile is nonsense, delete it(s edited version)\ncommit-working-tree-contents: Now you have the undesirable somefile~ saved\n\nEdit somefile, utterly changing it: Get backup called somefile~\nmv somefile newfile\ncommit-working-tree-contents: somefile~ saved, newfile lost\n\nEdit somefile a bit, move it to newfile. Make sure no backups left over.\ncommit-working-tree-contents: somefile deleted, newfile lost\n\nThis is /not/ easy to get right, as it depends on what the user wants, and\nthe random programs run in between git commands.\n\nYou need to tell git somehow what files you want saved, and which ones are\njunk. I.e., just the first command (unfortunately).\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"297371","messageId":"87zma316oc.wl%cworth@cworth.org","threadId":"43589","inReplyTo":"200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl","subject":"Re: [RFC] Two conceptually distinct commit commands","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-05T01:18:43Z","receivedAt":"2006-12-05T01:18:43Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 04 Dec 2006 21:52:38 -0300, \"Horst H. von Brand\" wrote:\n> > Commits the content of the working tree for the given paths, (or\n> > all tracked paths). Untracked files can be committed for the first\n> > time by specifying their names on the command-line or by using\n> > \"git add\" to add them just prior to the commit. Any rename or\n> > removal of a tracked file will be detected and committed\n> > automatically.\n>\n> Edit somefile with, e.g, emacs: Get backup called somefile~\n> Realize that somefile is nonsense, delete it(s edited version)\n> commit-working-tree-contents: Now you have the undesirable somefile~ saved\n\nThe semantics I intended to describe for commit-working-tree-content\nwould not add this file. That's a \"new file\" so would have to be\nmentioned either explicitly on the command-line or in a git-add\ncommand before it would be committed.\n\n> Edit somefile, utterly changing it: Get backup called somefile~\n> mv somefile newfile\n> commit-working-tree-contents: somefile~ saved, newfile lost\n\nOK, you've found a bug in my description above, (though not in the\nintended semantics). By \"rename...detected automatically\" I meant only\nthat the fact that a file has \"disappeared\" as part of a rename need\nnot be mentioned to git. The fact that the contents are made available\nas a new file name still would need to be told to git with \"git add\",\n(or would be worthwhile to mention \"git mv\" I suppose).\n\n> This is /not/ easy to get right, as it depends on what the user wants, and\n> the random programs run in between git commands.\n>\n> You need to tell git somehow what files you want saved, and which ones are\n> junk. I.e., just the first command (unfortunately).\n\nPerhaps I was too oblique in calling this thing\ncommit-working-tree-contents. This isn't some fabricated-from-scratch\ncommand. The intent of my message was that readers would recognize the\ndescription as matching what the current \"commit -a\" and \"commit\nfiles...\" commands do. So I really wasn't trying to invent anything\nreally different than those. So almost any problems of unexpected\nbehavior you can find almost surely apply to \"commit -a\" already.\n\nI did throw one new thing into the description, (that does not exist\nin current git). That's the mention that new files could be added by\nmentioning them explicitly on the command-line. This was intended as a\nway to allow a tutorial to sidestep the details of how \"git add\"\ninteracts with the index. If this one feature is a bad idea, it could\nbe dropped with no impact on the rest of the proposal nor my\ndiscussion of it.\n\nSimilarly, I worded the mention of \"git add\" to suggest it be done\n\"just prior to the commit\". Again, I did this just to avoid having to\nmention anything about the need to \"git add\" again if the file was\nedited between the time of add and the time of commit. That language\nis already proposed for the git-add documentation, so there's no need\nto repeat it all here.\n\n-Carl\n"},{"id":"297690","messageId":"el2hbm$oi0$1@sea.gmane.org","threadId":"43589","inReplyTo":"200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl","subject":"Re: [RFC] Two conceptually distinct commit commands","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-05T01:19:50Z","receivedAt":"2006-12-05T01:19:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Horst H. von Brand wrote:\n\n> Carl Worth wrote:\n> \n> [...]\n> \n>> Proposal\n>> -------\n>> Here are the two commit commands I would like to see in git:\n>> \n>> commit-index-content [paths...]\n>> \n>> Commits the content of the index for the given paths, (or all\n>> paths in the index). The index content can be manipulated with\n>> \"git add\", \"git rm\", \"git mv\", and \"git update-index\".\n>> \n>> commit-working-tree-content [paths...]\n>> \n>> Commits the content of the working tree for the given paths, (or\n>> all tracked paths). Untracked files can be committed for the first\n>> time by specifying their names on the command-line or by using\n>> \"git add\" to add them just prior to the commit. Any rename or\n>> removal of a tracked file will be detected and committed\n>> automatically.\n> \n> Edit somefile with, e.g, emacs: Get backup called somefile~\n> Realize that somefile is nonsense, delete it(s edited version)\n> commit-working-tree-contents: Now you have the undesirable somefile~ saved\n\nNo, you don't, assuming that you have *~ in .gitignore or .git/info/exclude\n\n> Edit somefile, utterly changing it: Get backup called somefile~\n> mv somefile newfile\n> commit-working-tree-contents: somefile~ saved, newfile lost\n\nNo, assuming that you use git-mv as you should.\n\n> Edit somefile a bit, move it to newfile. Make sure no backups left over.\n> commit-working-tree-contents: somefile deleted, newfile lost\n\nNo, as above.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296789","messageId":"200612050214.kB52E7mG027926@laptop13.inf.utfsm.cl","threadId":"43589","inReplyTo":"cworth@cworth.org","subject":"Re: [RFC] Two conceptually distinct commit commands","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-05T02:14:07Z","receivedAt":"2006-12-05T02:14:07Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Carl Worth wrote:\n> On Mon, 04 Dec 2006 21:52:38 -0300, \"Horst H. von Brand\" wrote:\n> > > Commits the content of the working tree for the given paths, (or\n> > > all tracked paths). Untracked files can be committed for the first\n> > > time by specifying their names on the command-line or by using\n> > > \"git add\" to add them just prior to the commit. Any rename or\n> > > removal of a tracked file will be detected and committed\n> > > automatically.\n\n> > Edit somefile with, e.g, emacs: Get backup called somefile~\n> > Realize that somefile is nonsense, delete it(s edited version)\n> > commit-working-tree-contents: Now you have the undesirable somefile~ saved\n\n> The semantics I intended to describe for commit-working-tree-content\n> would not add this file. That's a \"new file\" so would have to be\n> mentioned either explicitly on the command-line or in a git-add\n> command before it would be committed.\n\nHow do you distinguish a \"new file, same contents as old file\" from \"old\nfile, renamed\"? What is the difference between:\n\n mv somefile newfile\n\nand\n\n cp somefine newfile\n rm somefile\n\n?\n\nHow should\n\n cp somefile newfile\n vi somefile\n\nbe handled? How about\n\n cp somefile oldfile\n vi somefile\n\nor just\n\n mv somefile oldfile\n\n? Or\n\n cp somefile somefile.my-own-bakup\n vi somefile\n\n?\n\nThe whole problem is your description based on \"file renaming\" and\nsuch. AFAIU git has a list of file names it is tracking, and for those\nnames it keeps track of what the contents for each are at each commit. That\nthe name somefile had some contents that later show up as newfile (both\nnames tracked) is recorded just as that. You could /interpret/ this as a\n\"rename\" if somefile is then gone, but it could well be something else.\nBesides, you'd have to search for the old somefile contents among /all/\nnewfiles just to find out it was renamed. Better don't mix facts with\ninterpretation (== guesses on what operations came in between the snapshots\ngit takes). Note that it should never matter what strange ideas a random\nuser gets for naming her temporary backup files, or their git configuration.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"296366","messageId":"87y7pn138y.wl%cworth@cworth.org","threadId":"43589","inReplyTo":"200612050214.kB52E7mG027926@laptop13.inf.utfsm.cl","subject":"Re: [RFC] Two conceptually distinct commit commands","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-05T02:32:45Z","receivedAt":"2006-12-05T02:32:45Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 04 Dec 2006 23:14:07 -0300, \"Horst H. von Brand\" wrote:\n> What is the difference between:\n> mv somefile newfile\n> and\n> cp somefine newfile\n> rm somefile\n\nThere is no difference. This is git, a content tracker.\n\nSame for the rest.\n\n> The whole problem is your description based on \"file renaming\" and\n> such.\n\nOK. Strike the words \"or rename\" from the description, leaving just:\n\n\tAny removal of a tracked file will be detected and committed\n\tautomatically.\n\nThe rest of my analysis still stands, I believe. And I'd be glad to\naccept further suggestions on documenting these. The goal is simply to\nhave a user-oriented description of the semantics that are consistent\nbetween the current \"git commit -a\" and \"git commit files...\"\ncommands.\n\n-Carl\n"}]}