11–20 of 390 posts
To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to-learn features of git like "git * -p" which bring some interactivity in git commands.
I assumed all `git` commands would still be available even if one might prefer `gl` for some tasks, am I missing something?
"Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a "porcelain" of Git), you can always fall back on Git."
To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
http://eagain.net/articles/git-for-computer-scientists/
If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a").
What people complain about is often the CLI's inconsistency. For example "git branch -d" vs "git remote rm" to delete things. Then some things you want to do can be achieved with more than one sub-command in totally non-obvious ways. And some sub-commands do more than "one thing", like "checkout".
To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
A somewhat satirical example of this is Steve Losh's Git Koans.
http://stevelosh.com/blog/2013/04/git-koans
That's not to say I don't think the underlying ideas of how Git works makes sense. I certainly think it's a lot better than RCS, CVS and SVN (never tired Mercurial).
To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
You can create aliases to execute multiple commands at once.
The whole point of this tool is to add a common set of things on top of git.
The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to-learn features of git like "git * -p" which bring some interactivity in git commands.
The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to-learn features of git like "git * -p" which bring some interactivity in git commands.
To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
The CLI is indeed hard to learn. But the simplicity of git is not using it, it's its internal structures: http://eagain.net/articles/git-for-computer-scientists/ If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a"). What people complain about is often the CLI's inconsistency. For examp…
It's great that you can masturbate over it but I don't give a rat's ass, I just want to safely store and share my code with a VCS. I'd rather mercurial or darcs had won as they have sane (or even delightful) CLI, sadly the world disagreed.
That git's porcelain is a giant abstraction leak of the internal structures and plumbing is not a feature.
It seems inspired by Mercurial?
It doesn't match Darcs's CLI either.