On Sun, Feb 25, 2007 at 01:45:44AM -0800, Junio C Hamano wrote: > Peter Baumann <waste.manager@xxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html