On Mon, 4 Dec 2006 22:51:23 -0500, Theodore Tso wrote: > > 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. It's non-symmetric, yes, but it's what I would personally like. It's not an essential aspect of the proposal, so it could go either way as the git crowd decides. To explain my personal preference, I like the notion of all files being "untracked" until I inform the system about their existence. After that, I'd like the system to take care of them and notice when they get modified, or when they get deleted. > 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. The ability to configure --implicit-delete and --implicit-add to git-commit seems good. They're long enough arguments that > 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? This case is already under debate in a separate thread. There "git commit files", (which really is commit-working-tree-content already), currently errors out in this case, but the proposal is to allow it to proceed with the commit, (thereby "losing" the intermediate staged content). -Carl
Attachment:
pgpAjyPLNLPds.pgp
Description: PGP signature