Seigo: ending the cults of personality in free software [LWN.net]

Seigo: ending the cults of personality in free software

Posted Nov 9, 2012 4:46 UTC (Fri) by apoelstra (subscriber, #75205) [Link]

> Are you suggesting that git should not have had a command line interface? If so, which of the GUI toolkits should Linus have chosen?

I think the previous poster was suggesting that git should have had a consistent command-line interface with a sensible mental model behind it, rather than exposing the plumbing with a bunch of bash scripts and calling it a day.

But I disagree: I think he exposed everything needed for others to build the porcelain (something he had no time or incentive to do himself). He stopped there because he's a busy man, rather than because he's an awful designer.

Seigo: ending the cults of personality in free software

Posted Nov 9, 2012 5:13 UTC (Fri) by bojan (subscriber, #14302) [Link]

If Wikipedia history of git is correct (http://en.wikipedia.org/wiki/Git_%28software%29#History), Linus turned over the project after less than 4 months. That git had any UI at that point is a miracle in itself. That it was used to release 2.6.12, two and a half months after the beginning of development, is nothing short of genius.

So, yeah, I'm with you. He had better things to do. This does not disqualify him in any way from influencing other software development, by providing commentary.

Seigo: ending the cults of personality in free software

Posted Nov 9, 2012 8:34 UTC (Fri) by nhippi (subscriber, #34640) [Link]

UI in this case is command line interface - there can be good and bad command line interfaces. A typical example how git blows:

git checkout

Now, cvs and svn used checkout for well, checking out a remote repository to local directory. Git decided to confuse everyone coming from svn/cvs by reusing that command for something completely different. And worse, even in git it can be used for at least three totally different purposes:

git checkout foo # switch to branch foo
git checkout foo.c # reset foo.c the state of the last commit
git checkout -b foo bar # create a branch foo based on bar

Yes, you get used to such idiosyncrasy, but it still poor UI design.

Seigo: ending the cults of personality in free software

Posted Nov 9, 2012 11:15 UTC (Fri) by bosyber (subscriber, #84963) [Link]

I think the commands would be a bit clearer if you made the first command

git checkout bar
or even better, the middle command
git checkout baz.c

The first and last command are about checking out into the working the source tree as state at a certain label or branch. This way it is clear that that the middle command is the special one, checking out (now) file baz.c with the state as it is in HEAD. And that's a very convenient special case.

Maybe a better name could have been found for it though, that's quite true. The way I see it, everything is recorded in the index, and checkout allows you to get to a certain state as recorded in the index, even if that state is fetched from a remote location.

git's command structure

Posted Nov 9, 2012 12:30 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

You forget that the repository from which you are fetching stuff is local in git. CVS/SVN simply has no concept of remote changes to bring over. And git checkout -b newbranch is just a convenient shortcut for git branch newbranch; git checkout newbranch.

Yes, git's command line could be more regular, better thought out. But it sort of grew organically; changing it to something "more logical" (unless it is small step by small step, as is happening) is sadly out of the question (too many fingers know the current commands by now).

Seigo: ending the cults of personality in free software

Posted Nov 9, 2012 17:41 UTC (Fri) by wirespot (guest, #87759) [Link]

git was never meant to be any kinds of compatible with svn or cvs. Linus does not think very highly of svn (to put it mildly), so of course he wouldn't feel bound by its design. Any naming similarities between the git and svn commands are coincidental.

Any confusion you may harbor about svn vs git checkout is therefore of your own doing. Personally, I blame those "quick git intro for svn users" tutorials.

Now, to clarify your confusion. svn checkout, switch and reset do the same thing: they get files from a repository into a working copy. svn chose to use three different commands for this, whereas git chose just one.

You may still consider that svn's approach was better, and that's fine... but please don't say git is "confusing" when it was you who made the wrong assumptions.

Seigo: ending the cults of personality in free software

Posted Nov 9, 2012 23:13 UTC (Fri) by wookey (subscriber, #5501) [Link]

I find git's command interface hopelessly confusing too. Git itself is clearly rather clever. The command UI is deeply inconsistent even after you've munged your mental model into something git-shaped. The other surviving VCS's (svn, hg, bzr) have a more logical set of commands that make them a lot easier to get started with. It's unfortunate that we are going to be stuck with git's peculiar command set for evermore. I don't have an opinion on to what degree this is Linus's fault - but it's definitely someone's. I certainly couldn't care less what Desktop he uses, and thought that aseigo's comments on the general issue were pretty sound.

Seigo: ending the cults of personality in free software

Posted Nov 12, 2012 17:19 UTC (Mon) by jwakely (subscriber, #60262) [Link]

We're not stuck with it forever, for instance 1.8.0 says:

> "git branch --set-upstream" is deprecated and may be removed in a
> relatively distant future. "git branch [-u|--set-upstream-to]" has
> been introduced with a saner order of arguments.

That particular one has caught me out a few times.