Re: [RFC] Two conceptually distinct commit commands

From: Theodore Tso <tytso@mit.edu>
Date: Dec 5, 2006, 03:51 UTC
Message-ID: <20061205035123.GA8831@thunk.org>
In-Reply-To: <87d56z32e1.wl%cworth@cworth.org>

On Mon, Dec 04, 2006 at 11:08:22AM -0800, Carl Worth wrote:

Show 17 quoted lines

>
> 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.

I think this is a very interesting proposal, although I think I disagree with the last part:

      Any [rename or] removal of a tracked file will be detected and
      committed automatically.

If adds aren't going done automatically (because otherwise you have problems with foo.c~ accidentally getting checked it), then it's non-symmetric to expect that deletes will also happen automatically. It's relatively rare that files are removed or renamed, and sometimes files accidentally disappear.

So in the case where there are no pathnames given to "git commit-working-tree-content", I would argue that it does not do any implicit "git add" on new files NOR any implicit "git rm" on missing files unless the user actually specifies an --implicit-add or --implicit-delete option, respectively. If users want to make --implicit-add and/or --implicit-delete the default, that could be a configuration option, but I don't think it should be a default.

A second issue which you left unspecified is what should commit-working-tree-content do if the index != HEAD. In particular, in this case:

edit foo.c git update-index edit foo.c git commit-working-tree-content foo.c

What should happen to foo.c in the index? Should it be stay the same? Should the contents be replaced with version of foo.c that has just been commited? The latter seems to make sense, but runs the risk of losing the data (what was in the index). The former has the downside that the index might have a version of foo.c which is older than what has been just commited, which could be confusing. Or should git commit-working-tree abort with an error message if index != HEAD?