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 something other than git. That's a lot more work obviously, but git internals were defined to enable just that! Then in the fine print you could say "oh btw there's git under there for anyone that needs it". That's my idea, but maybe it would be better to just use Mercurial?
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.
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 does across any paradigm.
Abstractions make things easier for the human in many cases. If Legit increases the productivity of a team of developers and gets newbies using the Git VCS, more power to them and its use. They can learn the internals later.
> 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.
> you join a project that uses assembly language, which you find too hard to learn, so you decide you'll be using Ruby instead.
That's not my point. My point is that if legit gets people into using Git as their VCS, it seems silly to attack the idea because it isn't the current norm of engineering. Lessening barrier of entry to using a powerful VCS is not bad in and of itself. Not everyone jumps into assembly language. Plenty jump into higher-level languages and find themselves deeper in the rabbit hole as time progresses.
To a newbie, this legit script appears far more accessible than git's stock interface. Is it bad that GUIs exist because the command-line is often more powerful to an experienced user? Why is it so bad that this tool exists and can be used to increase overall engagement and entry into the world of Git?
The idea of a clean abstraction is you can predict what a particular operation will do without knowing its internal implementation.
For higher-level languages, this is generally true for the effect of a command: you can work out what a line of Ruby does without needing to think about the underlying assembly language. There are other abstractions (aka levels/layers), such as virtual memory, the OS and the implementation of the CPU itself in terms of architecture, transistors, silicon doping. (Sometimes these abstractions are said to still be "leaky" because to understand performance issues often requires knowing the underlying implementation - that's important but distinct from just knowing what it will do.)
A common criticism of git is that the abstraction is not clean - you need to know what it actually does underneath in order to predict that a command will do. It's not just a problem of an inconsistent UI (though it is that), but that the user model that the command sets out (the abstraction) does not match up with what git will actually do.
The OP's criticism is that legit (great name BTW) doesn't address this: people will use this simpler, friendlier UI, and inexplicable and weird dangerous things will happen (e.g. data loss). C++ might blow your leg off, but git can make you never have existed.
NB: I haven't looked at legit closely enough to tell if this criticism is valid (and OP offers no support - OP, please elaborate). I'm just clarifying the issue.
+1, If you just take 2 hours and read the entirety of progit.org (including the section on internals) all of these workflows on top of git start to look unnecessarily confusing.
-1, as a git user who finally submitted to learning the internals, I think this is not the right way to design software. I realize linux/et al are all geek inspired technology festivals, but to imply that a good User Interface and human accessible commands are unnecessary is... silly, the rhetoric reminds me of the elitist GNU/linux propeller heads back in 1999 who would constantly and derisively snort in disdain at "Windoze" users because they didn't know how to do a find / -name myfile.txt -print. Especially the one's who argued vehemently that the '-print' option made any sense whatsoever.
It's clear that you don't agree with the principles behind gits design. Why not use hg instead? It's a perfectly viable alternative and provides many of the benefits.
Just learn regular Git rather than re-inventing the language.