Re: [RFC/PATCH] Fix git-diff --cached to not error out if HEAD points to a nonexistant branch

[Peter Baumann <waste.manager@gmx.de>]

On Sun, Feb 25, 2007 at 01:45:44AM -0800, Junio C Hamano wrote:
> Peter Baumann <waste.manager@gmx.de> writes:
> 
> > ..., but in the same sentence you have to say
> > "Oh, did I mention that it doesn't work until you have made a first commit?"
> 
> Well, you do not even have to mention that if you are explaining
> things correctly.  If something does its thing relative to the
> latest commit, then it obviously would not work until you have
> that "latest commit".  There is _no_ initial "empty" commit in
> git.
> 

Yes. I know that there is no empty commit. But at least it's me thinking
that I start with "nothing" from the beginning.

But thats how people learn git! I _know_ of three people who just want
to play with it by creating a new repo with git-init-db (yes, that was
v1.4.4.4), doing git-add etc and start wondering why git diff didn't
show what the expected. After mentioning the index they realised that
they have to specify --cached to diff to get what they want (they have
used svn). Starting from a freshly initalized repo they played some more
and actually got _bitten_ by the confussing error message. At least put
your patch with the sane error message into git, so they would have
gotten a clou what went wrong if I couldn't convince you otherwise.

But I _really_ think that making it the same behaviour as in
"log.showroot = true" to show a diff against an empty tree.

> I think getting people used to that concept early on would
> actually avoid such confusion.  In that sense,...
> 

But people will start using git in newly created repos! You don't want
to clone the kernel to just see if that new SCM system fits your needs.
You start by creating some test repos to fool around and later throw
them away. They did it that way and so was I.

Not to mention that I think the majority of the users don't even have a
_need_ to go down to the plumbing commands! At least I am totally happy
with what the porcelain offers me and I could get all my work done with
it (commit, diff, rebase, merge, log ...)

Side note: Not that it matters, but they gave up on git because they found
it to confusing (remember, it was v1.4.4.4). All those "strange" concepts
like the index, diff not working as expected and those strange errors ...
and they actually had some work to do and didn't have the time to fully
master git, so they staid with svn.

I'll try to convince them again that git is much
superiour to svn, after git-core 1.5.0 is available in debian because I
_know_ the won't bother to compile it themself. For them, a SCM is just
a tool to get the work done. But with the new git-gui I have convincing
argument to try git again and it gives them time to acomodate to the
"new" behaviour of their SCM.
And obviously the learning curve is now much flatter than in v1.4.x.

-Peter

> > The plumbing commands are a diffrent story.
> 
> ... I do not think the plumbing should be a different story.
> Otherwise you would confuse people when they start learning the
> plumbing.
> 

see above