On Thu, 30 Nov 2006 17:32:22 -0800 (PST), Linus Torvalds wrote:
quoted text
>
> The old argument by incredulity. The fact that you cannot see it doesnt'
> change the fact that I use it all the time.

I'm sorry, Linus. I'm really failing to communicate with you somehow
here.

I _do_ use this all the time too. I don't need you to explain it to me
again. I get it, I like it, I use it. That's not at all what I'm
trying to discuss here.

quoted text
>  - your argument is that cannot understand how anybody would ever want to
>    use this.

Nope. I get it and I use it. Most commonly I do things like
"update-index;commit" to separate independent changes, (I could use
"git commit explicit/files" instead but I *gasp* actually enjoy being
able to manually stage things in the index first).

What I'm trying to say is that the _defaults_ are not well geared
toward helping new users do what they want to with git.

quoted text
> That's really what it all boils down to. That's your ONLY argument. You
> didn't actually answer any of me explaining _why_ it's how it works, and
> why it _has_ to be why it works. Your argument just boils down to "I can't
> believe it's useful to be consistent".

I do understand how git works. I understand your points about
filenames and content. I understand that.

One thing you never really answered was my conversation with a new
user that left the user with the impression of "git is bizarre". How
can I fix that conversation?

The idea I have for improving this is to do nothing more than change
the default semantics for one command to the semantics of that same
command with a single-letter option. You keep saying that my idea is
brain-damaged, (that carrying the filename from "git add" to "git
commit" without the old contents would violate something fundamental).
But "commit -a" already exists and does _exactly_ what I'm asking for
here. People use that without destroying git's model. Why would it
necessarily be so evil to do that by default?

By the way, none of the "confusion" arguments are coming from me
directly. They're coming through me by proxy, (on behalf of people
I've seen deciding against using git). Personally, I love git and plan
to continue using it forever. I'm very happy with it. I'm even
comfortable with all of the aspects of its interface that I'm arguing
against changing here, (which really are not big fundamental
things). I just think its harder for new people to get to that point
than it should be.

quoted text
>  - the "git add file ; change file ; git commit" behaviour is absolutely
>    REQUIRED once you get the whole "git tracks content" logic. Doing
>    anything but committing the old version (the one you added) would be
>    illogical and wrong, because it's strictly against the whole POINT of
>    tracking content.

Here's another question based on that example. You say above that
committing the old version is the only logical thing to
do. Separately, you say that after adding file-a and file-b it's often
convenient to be able to commit file-a without file-b.

So, given the following:

	echo a > file-a
	echo b > file-b
	git add file-a file-b
	echo a-not-ready-yet > file-a

How could I do both of these at once? That is, how can I commit the
_old_ version of file-a, (the only logical choice), but not commit
file-b? There's no commit command that does that is there? (I don't
think that's a fault in git since I think this would be a fairly
exceptional thing to do).

quoted text
> So. That's what it boils down to. Your personal incredulity against
> fundamental concepts and real usage.

[I'll snip the rest, because I really do think I understand, agree
with, and accept the fundamental concepts of git.]

But as for "real usage", by far, the thing I want to do most often is
to commit the state of my files as the exist in my working tree at the
time of commit. Any time I do anything else, I'm well aware of it, and
I'm quite happy to do "special" index-manipulating commands, (taking
advantage of the fundamental, content-tracking nature of git to do
it).

I think the defaults for git-commit should reflect that aspect of real
usage. That's all.

-Carl