Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Am I the only person who has never really been bothered by Git's UI? I can't remember ever being worried by its quirks and found it pretty easy to pick up...


I learned Hg before Git. Hg took about a day to master, but I still feel I haven't mastered git after using it for years. The following article will give you an idea of the differences between hg and git in terms of ui.

http://stevelosh.com/blog/2010/01/the-real-difference-betwee...


`git checkout -b` is one of the few things that I actually think git's default CLI got wrong. The primary thing that is doing is creating a branch, checking it out is kind of tangential in a way; I think that it should be `git branch -c`

I feel strongly that `git checkout file` is correct though. What that operation is doing is taking something out of the DAG and putting it into the working tree. It's the same deal, the only difference is instead of pulling a tree object (associated with a commit) from the DAG into the working tree, you are instead pulling a glob. It makes intuitive sense to me that these two operations would be accessed through the same command. Furthermore, using the name 'revert' would make much less sense in the rather frequent case that you want to pull a blob from a commit that is not the current HEAD. Is it really "reverting" if I am pulling a file from a future commit in another branch into my working tree? I don't think naming commands after less powerful concepts is a good design decision.


I've been using it for 2 years and I still end up googling almost everything beyond pull/commit/push.


I find it has a lot of unnecessary complexity. Does anyone advertise jobs using CSV, or SVN these days?

No, they all want experience using Git. Do they actually need a distributed version control system? Probably not.

I am sure git is great for the complexities of developing the Linux kernel from remote locations, but most projects are not that. I would prefer something that is less distracting to the task in hand.


Have you worked on medium/large teams and with advanced features such as submodules? (not accusing you of anything, just curious).

In my experience, many things were weird but just had to be learnt, submodules on the other hand, that's pretty crazy!


I've also never been bothered by Git's UI. I read through the official documentation several years ago, and then just used it, with occasional reference to the man pages. It's very straightforward to me, and easier to use than many other systems. For example, I feel like I have to take much more care when using SVN directly to avoid errors, rather than through git-svn.

I sometimes feel like I'm the only one; I'm glad to hear that I'm not alone.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: