Git 2.0 is here | Hacker News Reader

Git 2.0 is here

blogs.atlassian.com

143 pointsdurdn51 comments

Full of goodies? Meh. Yes, some default behaviour changed in what I think are mostly good ways.

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.

I have to admit I didn't even the notice the title till I read your comment :) I think may brain has stopped processing headlines.

For those wondering, the original title of the HN post (changed just minutes ago) was "Git 2.0 is here and it's full of goodies"

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...

Nope. In fact, Felipe Contreras has an excellent article he just posted about that exact topic: http://felipec.wordpress.com/2014/06/05/whats-missing-in-git...

That blog post is 100 times more interesting that the above article.

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.

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 :/

I always found the `git remote -v` command really weird.

Why `-v`?

verbose?

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.

"A foolish consistency is the hobgoblin of little minds" -- Emerson

Certainly. But command line consistency is not foolish.

Consistency isn't always foolish.

Their choice to stay consistent with their initial terrible ui design is the type of foolish consistency this quote is probably referring to.

Ah, was that not Larry Wall moments before inventing a language intended to parse bashing one's head against the keyboard?

Downvotes demonstrating my point.

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.

[1]: http://semver.org/

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.

Why "they"? Why not you? There have been other Git frontends in the past; why not write a new one that behaves as you'd like?

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.

Edit: changed symlink to git file, bad memory

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.

For an example of difference in output, see http://stackoverflow.com/questions/3921409/how-to-know-if-th...

"""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.

I feel like the addition of a SERGEANT version would be more appropriate.

And something like is announced waaay before it comes out so people are ready for it.

Just because semantic versioning allows breaking changes doesn't mean Git SHOULD break compatibility.

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.

UI consistency is probably one of the big reasons to use Mercurial.

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.

until you run "git help pull" and go WHAAA?

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.

It would be cool is source tree supported ECDSA keys (looking at you atlassian) :)

When do we get a git commit --undo alias? :)

Yes, please. I don't use it often, but when I do "hg rollback" makes my life simple.

git reset HEAD^

Add --hard, --mixed, --soft for different effects. This command itself can be undone by going through git reflog and finding the appropriate commit.

To add to this, git-reset enables much more than simply 'undoing' the last commit, so it could not be adequately replaced with `git commit --undo`.

So, you might want to learn about how to put an alias into your rc file.

You mean git revert?

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.

In that case, git reset

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".

Reply on news.ycombinator.com