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.
Legit. Git for humans
51–60 of 136 posts
Re: Legit. Git for humans
#52Earlier 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.
The only way this could be justified is as a concept build to pass back to the community.
Re: Legit. Git for humans
#53Oh 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...
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
#54Oh 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?
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
#55I 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…
Re: Legit. Git for humans
#56I 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…
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
#57Earlier 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?)
Re: Legit. Git for humans
#58Earlier 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?)
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
#59It 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 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)