Re: [Census] So who uses git?

Linus Torvalds <torvalds@osdl.org> writes:

This "I thought I was only checking in the two-liner I did as the last step but you committed the whole thing, stupid git!" confusion feels to be a parallel of "I thought I was only checking in the files I specified on the command line but you also committed the files I earlier git-add'ed, stupid git!" confusion.

Taken together with your "during a partially conflicted merge" example, it feels to me that the simplest safety valve would be to refuse "git commit paths..." if the index does not exactly match HEAD. Not just mentioned paths but anywhere.

People who do not like this can set in their config file some flag, say, 'core.index = understood', to get the current behaviour.

The reason I am bringing this up is because of this command sequence:

	# start from a clean tree, after 'git reset --hard'
        $ create a-new-file
        $ git add a-new-file
        $ edit existing-file
        $ edit another-file
        $ git commit existing-file

There is no question we do not commit "another-file" and we do commit changes to the "existing-file" as a whole. What should we do to "a-new-file", and how do we explain why we do so to novices?

We can argue it either way. We could say we shouldn't because "commit" argument does not mention it. We could say we should because the user already told that he wants to add that file to git. Either makes sort-of sense from what the end user did.

I think a file "cvs add"ed is committed if whole subdirectory commit (similar to our "commit -a") is done or the file is explicitly specified on the "cvs commit" command line, and that may match people's expectations. That's an argument for not committing "a-new-file". But to be consistent with that, this should not commit anything:

        # the same clean tree.
	$ create a-new-file
        $ git add a-new-file
        $ git commit

Which is counterintuitive to me by now (because I played too long with git).

We could make "git commit" without paths to mean the current "-a" behaviour, which would match CVS behaviour more closely. However, it would make commit after a merge conflict resolution in a dirty working tree _very_ dangerous -- it may give more familiar feel to CVS people, but it is not an improvement for git people at all. I would rather not.

Right now, "git add" means "stage this for the next commit in the index". If we change the semantics of "git add" to mean "I am not adding it for the next commit yet; I am just letting you know there is a file in the working tree so that you can keep an eye on it for me", using the intent-to-add index entry I've mentioned a couple of times, I think the above problem might naturally be solved. For people who do not use update-index, "commit -a" and "commit paths..." are the only two ways to actually check-in anything to the index file for the next commit ("git add" alone does not count). "commit -a" would do the equivalent of current "update all the not-up-to-date file to the index and then commit", which would include the intent-to-add paths.