
Git 2.0 is here - durdn
http://blogs.atlassian.com/2014/06/happened-git-2-0-full-goodies/
======
michh
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.

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

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

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

~~~
ma2rten
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...](http://stevelosh.com/blog/2010/01/the-real-difference-between-
mercurial-and-git/#the-big-difference)

~~~
Crito
_`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.

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

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

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

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

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

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

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

~~~
Crito
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`.

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

