Live data from Hacker News

Legit. Git for humans

git-legit.org

51–60 of 136 posts

Re: Legit. Git for humans

#51
Like anything else in software development, the hard part to learn is the abstractions, not the syntax. People struggle with git because it's an immensely powerful tool. "git reset" has quite simple syntax, but it confuses the hell out of even experienced git users because it's very clever and potentially very dangerous.

Of the altered syntax in Legit, "switch", "sync" and "publish" make sense, but "harvest", "sprout" and "graft" are no more intuitively obvious than the git equivalents.

Re: Legit. Git for humans

#52
post #46

Earlier quoted context omitted.

> Erm... push behaviour can be changed using config Right, and isn't that what legit is providing here? Sane defaults. I'm in favor.

The point is, the best way to improve suboptimal behavior in an open source project is to engage with the project and advocate changing the behavior. If there is truly a defect, or a behavior that so needlessly violates the principle of least surprise, then fix it at the project level.

Completely agree... I don't understand changing an existing CLI... why not suggest improvements to the actual project?

The only way this could be justified is as a concept build to pass back to the community.

Re: Legit. Git for humans

#53

Oh dear. Please, no. Just, no. git's user interface is terrible and very counter-intuitive, but if you want to work in a team or, more to the point, be productive and leverage what git has to offer, do take the time to learn its native user interface. Related article: http://beust.com/weblog/2010/04/06/git-for-the-nervous-devel...

That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is?

Engineers seem to treat mastering the command line and complex tools as a badge of honour, and as a way of differentiating themselves from the noobs. If there is really an easier way then is that really a bad thing?

Re: Legit. Git for humans

#54

Oh dear. Please, no. Just, no. git's user interface is terrible and very counter-intuitive, but if you want to work in a team or, more to the point, be productive and leverage what git has to offer, do take the time to learn its native user interface. Related article: http://beust.com/weblog/2010/04/06/git-for-the-nervous-devel...

That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is? Engineers seem to treat mastering the command line and complex tools as a badge of honour, and as a way of differentiating themselves from the noobs. If there is really an easier way then is that really a bad thing?

> That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is?

We're not talking about a different interface here but a new terminology.

It's a bit like saying that you think English is too hard so you'll be communicating in Spanish from now on. This is not a realistic decision in a world where you need to work with a lot of people who all communicate in English.

Re: Legit. Git for humans

#55

I strongly disagree with the purpose of this. It still has precisely the same problem that regular git has: you need to understand the language behind it. Just learn regular Git rather than re-inventing the language.

I don't disagree with the purpose , the git CLI interface is pretty inaccessible to non-developers—more than it needs to be. But you're totally right about the implementation. This just adds more commands under the git namespace, muddying the waters as much as providing a simple interface. If the goal is to make git for mere mortals then what is necessary is to create new porcelain from the ground up and call it some…

'porcelain' is completely new to me in this context. Could you explain what it means? (and who uses it?)

Re: Legit. Git for humans

#56

I strongly disagree with the purpose of this. It still has precisely the same problem that regular git has: you need to understand the language behind it. Just learn regular Git rather than re-inventing the language.

The same argument could be used with assembly language vs. Ruby/Python, but that doesn't stop people from using higher-level abstractions to get things done easily. They exist to streamline a process. I see much ado about nothing in these comments. Is it really that awful to alias away an odd set of tools that sometimes contradict one another? That's what every high-level language does. That's what every decent UI do…

> The same argument could be used with assembly language vs. Ruby/Python, but that doesn't stop people from using higher-level abstractions to get things done easily.

That's not the right analogy.

The situation here is more: you join a project that uses assembly language, which you find too hard to learn, so you decide you'll be using Ruby instead.

Re: Legit. Git for humans

#57
post #55

Earlier quoted context omitted.

I don't disagree with the purpose , the git CLI interface is pretty inaccessible to non-developers—more than it needs to be. But you're totally right about the implementation. This just adds more commands under the git namespace, muddying the waters as much as providing a simple interface. If the goal is to make git for mere mortals then what is necessary is to create new porcelain from the ground up and call it some…

'porcelain' is completely new to me in this context. Could you explain what it means? (and who uses it?)

"Porcelain" is git terminology for the user interface on top of the git low-level plumbing:

http://progit.org/book/ch9-1.html

Re: Legit. Git for humans

#58
post #55

Earlier quoted context omitted.

I don't disagree with the purpose , the git CLI interface is pretty inaccessible to non-developers—more than it needs to be. But you're totally right about the implementation. This just adds more commands under the git namespace, muddying the waters as much as providing a simple interface. If the goal is to make git for mere mortals then what is necessary is to create new porcelain from the ground up and call it some…

'porcelain' is completely new to me in this context. Could you explain what it means? (and who uses it?)

In more general terms, the 'porcelain' is the user-friendly interface commands, and the 'plumbing' is the internal commands.

With Git, it's often said that some of the 'porcelain' commands only make sense in the context of the 'plumbing' ones, and you should understand the internals first before being able to use the more user-friendly interface. It's things like this that lead people to create more friendly interfaces like Legit here.

Re: Legit. Git for humans

#59
post #40

It seems that git is the new regex. People are actively building things around instead of learning the rules. I suppose that came from writing being easier than reading.

Well, regex has a horrible syntax too. The mathematical principles underneath are good, but the standard regex syntax is arcane and values brevity over readability, modifiability, etc.

I don't want to venture too far off-topic, but when the Perl 6 folks re-designed regexes, they found out that they weren't really designed for anything; the syntax just grew, and common features were sometimes longer than rare ones: http://www.perl6.org/archive/doc/design/apo/A05.html (section "Poor Huffman Coding").

I haven't studied enough of the Git plumbing to know what's going on underneath, but I suspect that the same thing is going on, where features are added without regard to other ones already present (feel free to correct me on this)

Re: Legit. Git for humans

#60
I personally like git-flow, but this is just a symptom of git inconsistencies, like git branch and git checkout both work with branches. I think it would be very useful to have higher level git that would be adopted as standard interface.
Post reply on HN