Am I the only one disappointed that they didn't go for a completely redesigned, consistent UI when making a shift to 2.0? I guess most just went with "everyone else is using git as is, so I have to learn the weirdness". But projects like EG are still being created - so it seems there's a need for improvements. Maybe in v3.0 they'll redo it...
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.
`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 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.
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.
Yeah, I was hoping for that too. Having totally inconsistent switches and parameters (How many different ways is to "list" something in git? -a -v -l depending on command?) depending on command drives me up the wall way more than in should :/
correct. If you allow the bare command 'git remote' to do anything, it might as well give back the remote names list. If you want more detail, pass -v as usual.
That would require a MAJOR MAJOR[1] version number increment because this change would break so much.
Looking at Git as it is now, I find it very unlikely to see a clean CLI in the nearest timeframe. Changes will happen (if they will) at a very slow pace.
I'm not saying they should change the `git` itself. They could go with `git2`, `giit` or whatever else and just use new interface for common backend code.
A number of reasons: Writing your own means dealing with changing internal behaviour. It means following changing output. It means not being able to reuse parts that already exist but are not exposed. It means deploying separate software where you don't necessarily have root/install rights.
Even if the interface you see as a user doesn't change, the internals do - for example submodules handling has been changed from a standard git dir to git file with directory link. This broke some of my scripts that made git interaction easier.
I don't want to slap something on top of git and hope that there are no edge cases in state/output parsing. I want an actual first-class interface that has at least a bit of consistency between commands.
As you can see, I went that way and it's not usable long-term.
I don't buy this. Give me some concrete examples of how internals need to change. I have lot of git scripts which work off git plumbing and they didn't require any of what you mention. You just sound like an armchair critic otherwise.
I gave one example already. The implementation of submodule .git directory changed (git-file instead of a directory). The change meant I had to check the git version and have two different ways of doing the same thing or the interface I wrote failed.
"""As of git version 1.7.3.1, git status doesn't say anything about the rebase status.""" - so you're left with "does some file under .git exist" approach. It's unlikely to change, but I don't believe it's part of any external interface - when it changes in the future, it changes.
What does MAJOR MAJOR mean? I can't find it in the semver spec. They've changed the major version number - doesn't that mean they can change the API in any way they like?
MAJOR MAJOR is my very own invention and me being overly snarky. What I meant by that is that changing the CLI is a huge breaking change, and incrementing just the MAJOR component will not reflect the hugeness of what has happened.
Agree with your comment and almost all replies here. I'd love to switch to Git just because of Github but the UI is holding me back. Tried Git for a few months, switched to Hg & found it a lot more easy. I just don't like the swiss army knife approach of Git.
As a refugee displaced by the Great VCS Wars, I certainly agree. Bazaar's command line interface was the thing that made me initially lean towards it rather than git.
I hope I won't get downvoted for this - but it looks like Git is going the C++ way - tons of very intricate details and features very few people use, that make the learning curve ever steeper.
Now, most people work with, what, 20% of git, tops? Why should we care about bloat if we don't use it? To me, there are two main issues: a. There are 3 ways if not more of doing every single logical operation; and b. The clutter makes it harder to find how to do stuff that is not trivial when you need it.
I really wish Git would be cleaned up and made more intuitive, rather than have more features and abstract more implicit behaviors.
I don't think that the addition of more features "makes the learning curve even steeper". It just extends the curve a bit farther. If using these new features where key to using Git, then yes, it would make it steeper.
For the 80% of people who want to just want to pull, commit, merge, push--that functionality is still there, and has even been improved in the last release.
Pretty excited to see this until I opened the page and saw that the changes were relatively low-level and things I'm unlikely to ever need or even run into.
That reverts the diff a commit causes, but doesn't undo `git commit` which is what I suspend OP meant. Of course, there's `git reset` for that, but they were asking for an alias.
Regarding the UI issues, I think that libgit2 takes a good approach by separating the UI from the core in a clear way. This way, you have a library that contains all the capabilities that are needed, but a UI can take advantage of that in anyway it wants.
For example, a UI could have a "create new branch" feature, which internally does a "create new reference pointing to commit xxx; checkout a working copy of branch y".
There are some new features, some of them useful for a lot of people, some of them not so much.
It's good, but full of goodies? Nah. That's overselling it.