Re: Two ideas for improving git's user interface

From: Junio C Hamano <junkio@cox.net>
Date: Feb 2, 2006, 00:38 UTC
Message-ID: <7v1wym4msq.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87lkwupsbr.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 5 quoted lines

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

Show 6 quoted lines

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

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