Re: Cleaning up git user-interface warts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds escreveu:
 - git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.

that's not a good argument; the set of git users is a small subset of those
that looked at git, and dismissed it because they couldn't wrap their heads
around it.

And I've said this again, and I'll say it once more: that has basically _nothing_ to do with whether you spell "pull" as "pull" or "merge".

The reason people have trouble wrapping their heads around git is because they have been braindamaged by CVS and SVN, and just don't understand the fairly fundamental new concepts and workflow.

> I claim that those "annoying little issues" are totally made up by
> people
> who had trouble wrapping their minds about git, and then make up
> reasons
> that have nothing to do with reality for why that might be so.

Let me put this more personally: I continue to be bitten by stupid naming issues, and the myriad of little mostly non-orthogonal commands. My head is doing just fine otherwise, and has no problems wrapping it around the core of GIT. I've also used Darcs for almost a year. Darcs, which is much less overwhelming.

This is not about CVS or SVN, so don't put them up as a strawman.
If you want to argue that my brain is warped, use other distributed VCs as an example.

The following

  mkdir x y
  cd x
  hg init
  echo hoi > bla
  hg add
hg commit -m 'yes, I am also too stupid to refuse explicit empty commit messages'
  cd ../y
  hg init
  hg pull ../x

pretty much works the same in Darcs, bzr and mercurial.

With GIT, this is what happens

[hanwen@haring y]$ git pull ../x
fatal: Needed a single revision
Pulling into a black hole?

[hanwen@haring y]$ git fetch ../x
warning: no common commits
remote: Generating pack...
Done counting 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Total 3, wremote: ritten 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
 100% (3/3) done

[hanwen@haring y]$ git checkout
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name HEAD

[hanwen@haring y]$ git branch master
fatal: Needed a single revision

at this point, I resort to adding a bogus commit and/or editing .git/HEAD by hand. I'm sure there is a saner way of doing it, but I still haven't found out what it is.

This might not be typical GIT use, but it does show the typical GIT user experience, at least mine.

If you want to have another example of how not to design a user-interface, try the above on Monotone.

That's totally different from then arguing about stupid naming issues.

Peopel seem to believe that changign a few names or doing other totally _minimal_ UI changes would somehow magically make things understandable. I claim that isn't so at all. The fact is, git is different from CVS and SVN, and git _has_ to be different from CVS and SVN. It has to be different because the whole model of CVS and SVN is simpyl fundamentally BROKEN.

It's worth trying to get those on board by fixing the annoying
little issues that have popped up in this thread.


Let's face it, you could just alias "merge" to "pull", and it wouldn't really change ANYTHING.

I don't want ANYTHING to really change, I just want a sane interface to it.


--
 Han-Wen Nienhuys - hanwen@xxxxxxxxx - http://www.xs4all.nl/~hanwen
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]