I'd have to agree. Git is very Unix - simple commands do one simple thing - it doesn't need complicating by opaque commands that do lots of things at once.
But Git commands map to what is going on in the code, which isn't necessary. I think an effort to make a true CLI for git should be encouraged. For example:
git push
Pushes everything, in every branch.
git pull
Whoops, won't let me do that without providing a branch.
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 phrasing is intentional - a new syntax needs to be substantially better (as opposed to slightly better) than the old one to justify adding an additional standard.
Incremental and clarifying progress is always beneficial.
I am on the fence as to whether this is clarifying or not. Git's problem is not just that the command structure is... esoteric, it's that once you're off the golden path, finding your way back onto the path is extraordinarily difficult.
I am unclear as to what extent legit mitigates the second (thornier) problem.
Looks like it's just aliases. You might as well just use 'git alias'. There's no need for a new universal set of commands - it defeats the idea of configuring your very own Git.
I disagree. A lingua franca is important. If these are indeed common operations, then it's important that everyone talking about, say, `git sprout` means exactly the same thing.
Exactly! And that lingua franca already exists. This is only useful if you would like a new syntax for personal use and you're too lazy to or don't want to use 'git alias'.
>Exactly! And that lingua franca already exists. This is only useful if you would like a new syntax for personal use and you're too lazy to or don't want to use 'git alias'.
Well, the lingua franca that "already exists" is the standard git syntax.
This syntax pains some people. Now, to alleviate the pain they could either use each their own aliases OR they could share a common new "lingua franca" of aliases.
That's what this project does.
In other words, what you're saying is:
1) a lingua franca is important
2) so use standard git, which is a lingua franca, or have your own personal aliases.
This just doesn't follow.
If a lingua franca is important, then, FOR THE SUBSET OF PEOPLE THAT DON'T LIKE GIT SYNTAX, to have a common alias lingua franca is also important.
It doesn't matter that it's less of a "lingua franca" that standard git-alese, because it is still a lingua franca for that subset, and solves the problem they have with the more established lingua franca.
