Carl Worth <cworth@cworth.org> writes:

quoted text
> To explain this, "just use -a" isn't enough, it would have to be
> something like, "always use -a or else 'git commit' just won't work
> and you can end up committing stale garbage". And perhaps "unless you
> also add the filename to the commit line, then it will start working
> again."

I do not think you have to make it sound *that* negative.  I
agree it may be counterintuitive until the user groks the index.

Let's assume that we will fix things to (1) require "--also" (or
"--incremental") to get the current "git commit paths..."
behaviour, (2) without any arguments we commit the index as is,
(3) with explicit paths we commit clean HEAD plus only specified
paths using a temporary index.  I think a fairer way to say what
you said would be:

        Always use -a, or explicit paths.  With -a all of your
        changes in the working tree are committed.  With paths,
        only changes to those paths are committed.

        Once you are comfortable with making commits this way,
        you might want to learn about index file and then start
        using 'git commit' without any argument.  This works in
        a way that cannot be understood until you learn how the
        index file works, so stick to "-a or explicit paths"
        rule for now.  That rule is good enough for everyday
        use.

And you can probably go a long way without ever knowing about
index.  Initially when I wrote the above two paragraphs, I said
"appreciated" instead of "understood".  But depending on your
workflow, you may not even need what "git commit" without
arguments would give you, in which case there is nothing to
appreciate about, so I changed the wording.

Old-timer git people seem to like what it gives them but that
does not mean everybody should marvel at what it does and adopt
the workflow to take advantage of the index file.

quoted text
> Here's a fundamental question I have, (and thanks to Keith Packard for
> helping me to phrase it):
>
> 	Is it ever useful (reasonable, desirable) to commit file
> 	contents that differ from the contents of the working
> 	directory?

What that means is people should always do "git commit -a".  Not
even "git commit paths...".  It matches _my_ sense of developer
discipline, especially for individual developers, but it is a
rather cumbersome straightjacket if enforced upon you in
practice.  It is a useful timesaver to be able to leave
unrelated changes around in the working tree.

quoted text
> I don't think it is, (but please let me know if I've missed some
> useful case).

I think I've already done this a couple of times today.

Your "git diff" is interesting, but I'd rather make them
completely separate command from "git diff".  Perhaps "git
ndiff" and "git ncommit", that assumes there is nothing but "git
commit -a" kind of commits.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html