threads / rfc / 43589

Re: [RFC] Two conceptually distinct commit commands

Subject: Re: [RFC] Two conceptually distinct commit commands

## tl;dr

5 messages between Dec 5, 2006 and Dec 5, 2006.

replies: 4people: 3as markdown or json

Horst H. von Brand· Dec 5, 2006, 00:52 UTC · lore
Carl Worth <cworth@cworth.org> wrote:
[...]
Show 18 quoted lines
> 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· Dec 5, 2006, 01:18 UTC · re: Horst H. von Brand · lore
On Mon, 04 Dec 2006 21:52:38 -0300, "Horst H. von Brand" wrote:
Show 10 quoted lines
> >     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).

Show 5 quoted lines
> 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· Dec 5, 2006, 01:19 UTC · re: Horst H. von Brand · lore
Horst H. von Brand wrote:
Show 26 quoted lines
> Carl Worth <cworth@cworth.org> 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· Dec 5, 2006, 02:14 UTC · lore
Carl Worth <cworth@cworth.org> wrote:
Show 7 quoted lines
> 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· Dec 5, 2006, 02:32 UTC · re: Horst H. von Brand · lore
On Mon, 04 Dec 2006 23:14:07 -0300, "Horst H. von Brand" wrote:
Show 5 quoted lines
> 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

← back to recent threads