3 ms·
I kinda conceptually disagree with approaches like this, for the same reason I dislike the official Github client: it renames some basic git concepts. e.g. git
by tudorizer 14y ago
I kinda conceptually disagree with approaches like this, for the same reason I dislike the official Github client: it renames some basic git concepts. e.g. git sync. How is this helpful when the dev is put in front of a situation (not configured server, new colleague who is not aware of legit)? Essentially I admire the work put into this project, I just question the goal.
- regularfry 14y agoIt's just a shortcut. The underlying operations haven't gone away. Abstractions are good.
- zephod 14y agoIn the general case, I agree. But working with Git you will very probably have to learn what's going on beneath the abstraction sooner-or-later (ie. when I'm working on a team larger than 1 person and the repo becomes a mess). So writing abstraction layers just increases the number of things that need to be learned.
- tudorizer 14y agoMy point exactly.
- silon3 14y agoAgreed. I don't use git, because I know that I would write wrappers for commands to be saner like SVN or mercurial and that is the wrong approach. Better to fork+rename git.
- imperialWicket 14y agoAgreed. Spending time generating aliases for commonly used commands and scripting commands together to form new (possibly more comfortable) command-wording are both fine once you use the product enough to learn which aliases and scripts would be productive. Providing a set of these alternatives as a wrapper is a dangerous alternative to newcomers, and has the potential to simply add confusion. I think these efforts must come after foundational product knowledge is achieved, not before. This effort seems to target those who do not yet have said knowledge.