Re: Two ideas for improving git's user interface

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

On Wed, 01 Feb 2006 16:38:45 -0800, Junio C Hamano wrote:
> 
> I do not think you have to make it sound *that* negative.

Sorry about that. I was just trying to emphasize the new-user
confusion, and perhaps I went overboard.

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

I'm sorry. I didn't succeed in phrasing the question the way I
wanted. Yes, it is useful to be able to leave unrelated changes around
in the working tree. So in that sense, it is clearly useful to be able
to commit something that is different (in a repository-wide sense)
than what is in the working tree.

The question I was trying to ask is, for a _single file_ is it ever
useful to commit contents that differ from the contents of the working
directory? Let's call this a "skewed file" in the index.

I haven't used git much yet, but I found two cases for when one might
end up committing a skewed file:

1) Modification of working directory after git-update-index or git-add.

   There has been discussion in this thread already that the user can
   get a confusing commit in this case.

2) git-read-tree -m	# without -u

   The git documentation already advertises that not using -u here
   leads to confusion. This one looks historical, and it's not obvious
   to me whether git-read-tree is used in practice without -u.

So, in both of those cases the skewed files seem to lead only to
confusion. Are there any non-confusing cases where it's useful to be
able to commit a skewed file?

If not, we should be able to simplify things since a lot of the
UI complexity being discussed (-a vs. no -a, path names vs. no path
names), hinges on the handling of skewed files.

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

I'd be fine with some other name than "diff" if strictly necessary,
but I'm not suggesting something that makes any assumption about "git
commit -a" only. What I want is a simple way to take any "git commit"
command and be able to examine the diff that it will be committing.

My workflow has been to always perform a final review of such a diff
while composing the commit message. I'd like to be able to do that
with git.

And I think this tool would make a very good learning tool for users
trying to figure out the various commit operations, (particularly if
we end up with different semantics for merge vs. non-merge, -a vs. no
-a, path names vs. no path names, etc.).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]