Re: Cleaning up git user-interface warts

Marko Macek [off-list ref] writes:

For people switching from CVS and SVN it would be much better if the
index was hidden behind the scenes by using different defaults:

git-commit -a
git-status -a
git-diff HEAD

BTW, currently there's a minor bug: git-diff HEAD doesn't work before
you make the first commit. Perhaps this should be special cased.

That's only a _bug_ in your implementation of the synonym for
"svn diff" which blindly used "git diff HEAD".

"git diff HEAD" is not a synonym for "svn diff" when HEAD does
not exist yet, because you are asking "please give me a diff
between the tree in the HEAD commit and my working tree files
through the index".  So if you are doing "git-svnish-diff"
Porcelain script, it should notice that HEAD does not exist yet
and take an appropriate action.  We do something similar in
git-status; the porcelain notices and acts differently when HEAD
is not there yet.

This "there is no HEAD yet" is not related to the index, but I
am skeptical about trying to hide the index from the end user.

You can make some things map more naturally to systems like SVN
and CVS than other things.  For example, Nico's proposal to
always use remote tracking branches and defaulting to use
refs/remotes/ would be a way to match UI of pull/push to another
existing system and that would work well (I am not agreeing to
the change to make 'pull' not to do the merge which would break
existing users -- I am just saying that the result would be self
consistent).  But things that have difference at the concept
level, I suspect no clever mapping to hide the differences would
work well.

The index is quite central to the way git works at the concept
level, and I think it is doing disservice to the end user to try
hiding it forever from them and failing to do so, rather than
being honest and teaching them the concept upfront.

But me thinking so does not necessarily mean you are forbidden
from trying.  Your efforts may result in a system where the
index is totally invisible and the end user never has to know
about it.

Junio C Hamano wrote:

Marko Macek [off-list ref] writes:

quoted

quoted

quoted

BTW, currently there's a minor bug: git-diff HEAD doesn't work before
you make the first commit. Perhaps this should be special cased.

That's only a _bug_ in your implementation of the synonym for
"svn diff" which blindly used "git diff HEAD".

My "implementation" is taken from git-diff man page. It seems obvious
that the situation before the first commit is just a special case if
we consider git-diff to be Porcelain (which I do).

Yes, "git diff" is a Porcelain.  No question about it.

I do not consider the current behaviour of "git diff HEAD" that
complains instead of giving runs of "foo is a new file and no
diff is available for it" a bug; you asked for diff from some
commit but the commit you gave was bogus (does not exist yet).

git diff --root HEAD, perhaps?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Junio C Hamano [off-list ref] wrote:

The index is quite central to the way git works at the concept
level, and I think it is doing disservice to the end user to try
hiding it forever from them and failing to do so, rather than
being honest and teaching them the concept upfront.

But me thinking so does not necessarily mean you are forbidden
from trying.  Your efforts may result in a system where the
index is totally invisible and the end user never has to know
about it.

I agree with what you are saying about the index.

But in git-gui I found myself writing code on Monday which tries to
hide the index from the user unless he/she requested that the index
be made visible.

The reason is there are some users who I'd like to give git-gui to
who I'm not sure I trust to make sure their index is in sync with
their working directory before they commit.  In some cases I'm lucky
that the user even knows what directory their file is stored in.  :-(
Yes, there really are computer users who are afraid of directories
and command lines.

I probably could try to teach them to make sure the final file
is included in the index before committing, but I think that for
most of them they would find this to be just another couple of
mouse clicks they have to perform before every commit, meaning its
something that the #$@!*@!*@$# tool should just do for them.

-- 

Marko Macek [off-list ref] writes:

quoted

quoted

BTW, currently there's a minor bug: git-diff HEAD doesn't work before
you make the first commit. Perhaps this should be special cased.

That's only a _bug_ in your implementation of the synonym for
"svn diff" which blindly used "git diff HEAD".

My "implementation" is taken from git-diff man page. It seems obvious
that the situation before the first commit is just a special case if
we consider git-diff to be Porcelain (which I do).

Yes, "git diff" is a Porcelain.  No question about it.

I do not consider the current behaviour of "git diff HEAD" that
complains instead of giving runs of "foo is a new file and no
diff is available for it" a bug; you asked for diff from some
commit but the commit you gave was bogus (does not exist yet).
But if you feel strongly about it, it should be trivial to
special case the yet-to-be-born HEAD case and run the
equilvalent of:

	git ls-files | sed -e 's/$/ is a new file, no diff is available./'

in such a case.  Or you could even go fancier and do an
equivalent of:

	git ls-files |
        while read path
        do
		l=`wc -l <"$path"`
        	echo "diff --git a/$path b/$path"
                echo "--- a/$path"
                echo "--- b/$path"
                echo "@@ -0,0 +1,$l @@"
                sed -e 's/^/+/' <"$path"
	done

and you can claim that it makes it consistent with the case
where you already have commits.

But I happen to think that consistency is only of academic
interest.  After all, how often would one create a true "root"
commit?  We are not talking about creating a new repository that
starts its life as a clone of something else, but a truly empty
one in which the initial commit is made.  And how often would
one want to view "diff" from void while preparing for that
initial commit?  Both that low frequency _and_ general
uselessness of the output from either of the above shell
scripts, would it be worth "fixing" it?

I do not think it adds any real practical value, and does not
even have much to do with being user friendly.  I would put it
in the "when somebody is really bored and has nothing better to
do, then this _could_ be done" category.

Junio C Hamano wrote:

Marko Macek [off-list ref] writes:

quoted

For people switching from CVS and SVN it would be much better if the
index was hidden behind the scenes by using different defaults:

git-commit -a
git-status -a
git-diff HEAD

BTW, currently there's a minor bug: git-diff HEAD doesn't work before
you make the first commit. Perhaps this should be special cased.

That's only a _bug_ in your implementation of the synonym for
"svn diff" which blindly used "git diff HEAD".

My "implementation" is taken from git-diff man page. It seems obvious
that the situation before the first commit is just a special case if 
we consider git-diff to be Porcelain (which I do).

 

This "there is no HEAD yet" is not related to the index, but I

I agree, this is a separate issue.