6 ms·

Git 2.0 is here

143 points by durdn 12y ago

deleted 12y ago
[deleted]
viraptor 12y ago
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...
- izacus 12y ago
  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 :/
  - hughw 12y ago
    "A foolish consistency is the hobgoblin of little minds" -- Emerson
    - sopooneo 12y ago
      Certainly. But command line consistency is not foolish.
    - worklogin 12y ago
      Consistency isn't always foolish.
    - _broody 12y ago
      Ah, was that not Larry Wall moments before inventing a language intended to parse bashing one's head against the keyboard?
    - cgag 12y ago
      Their choice to stay consistent with their initial terrible ui design is the type of foolish consistency this quote is probably referring to.
    - hughw 12y ago
      Downvotes demonstrating my point.
  - sergiotapia 12y ago
    I always found the `git remote -v` command really weird. Why `-v`?
    - jaybuff 12y ago
      verbose?
      - rch 12y ago
        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.
- anton_gogolev 12y ago
  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/ http://semver.org/
  - viraptor 12y ago
    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.
    - lambda 12y ago
      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?
      - viraptor 12y ago
        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
        general_failure 12y ago
        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.
- girvo 12y ago
  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-v2-0-0/ http://felipec.wordpress.com/2014/06/05/whats-missing-in-git...
  - StefanKarpinski 12y ago
    That blog post is 100 times more interesting that the above article.
- vezzy-fnord 12y ago
  UI consistency is probably one of the big reasons to use Mercurial.
- stephen_g 12y ago
  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...
  - tootie 12y ago
    I've been using it for 2 years and I still end up googling almost everything beyond pull/commit/push.
    - collyw 12y ago
      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.
  - ma2rten 12y ago
    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-between-mercurial-and-git/#the-big-difference http://stevelosh.com/blog/2010/01/the-real-difference-betwee...
    - Crito 12y ago
      `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.
- enscr 12y ago
  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.
- andrewsomething 12y ago
  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.
amphibean 12y ago
When do we get a git commit --undo alias? :)
- lunarcave 12y ago
  You mean git revert?
  - michh 12y ago
    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.
    - eyko 12y ago
      In that case, git reset
- herge 12y ago
  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 12y ago
    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`.
- binarycrusader 12y ago
  Yes, please. I don't use it often, but when I do "hg rollback" makes my life simple.
- saraid216 12y ago
  So, you might want to learn about how to put an alias into your rc file.
exabrial 12y ago
It would be cool is source tree supported ECDSA keys (looking at you atlassian) :)
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
michh 12y ago
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 12y ago
  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.
- owenversteeg 12y ago
  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"
sdegutis 12y ago
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.
Osiris 12y ago
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".
dvirsky 12y ago
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 12y ago
  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 12y ago
    until you run "git help pull" and go WHAAA?

143 points by durdn 12y ago

deleted 12y ago

[deleted]

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

izacus 12y ago
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 :/
- hughw 12y ago
  "A foolish consistency is the hobgoblin of little minds" -- Emerson
  - sopooneo 12y ago
    Certainly. But command line consistency is not foolish.
  - worklogin 12y ago
    Consistency isn't always foolish.
  - _broody 12y ago
    Ah, was that not Larry Wall moments before inventing a language intended to parse bashing one's head against the keyboard?
  - cgag 12y ago
    Their choice to stay consistent with their initial terrible ui design is the type of foolish consistency this quote is probably referring to.
  - hughw 12y ago
    Downvotes demonstrating my point.
- sergiotapia 12y ago
  I always found the `git remote -v` command really weird. Why `-v`?
  - jaybuff 12y ago
    verbose?
    - rch 12y ago
      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.
anton_gogolev 12y ago
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/ http://semver.org/
- viraptor 12y ago
  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.
  - lambda 12y ago
    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?
    - viraptor 12y ago
      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
      - general_failure 12y ago
        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.
girvo 12y ago
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-v2-0-0/ http://felipec.wordpress.com/2014/06/05/whats-missing-in-git...
- StefanKarpinski 12y ago
  That blog post is 100 times more interesting that the above article.
vezzy-fnord 12y ago
UI consistency is probably one of the big reasons to use Mercurial.
stephen_g 12y ago
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...
- tootie 12y ago
  I've been using it for 2 years and I still end up googling almost everything beyond pull/commit/push.
  - collyw 12y ago
    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.
- ma2rten 12y ago
  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-between-mercurial-and-git/#the-big-difference http://stevelosh.com/blog/2010/01/the-real-difference-betwee...
  - Crito 12y ago
    `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.
enscr 12y ago
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.
andrewsomething 12y ago
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.

amphibean 12y ago

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

lunarcave 12y ago
You mean git revert?
- michh 12y ago
  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.
  - eyko 12y ago
    In that case, git reset
herge 12y ago
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 12y ago
  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`.
binarycrusader 12y ago
Yes, please. I don't use it often, but when I do "hg rollback" makes my life simple.
saraid216 12y ago
So, you might want to learn about how to put an alias into your rc file.

exabrial 12y ago

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

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

michh 12y ago

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 12y ago
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.
owenversteeg 12y ago
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"

sdegutis 12y ago

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.

Osiris 12y ago

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

dvirsky 12y ago

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 12y ago
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 12y ago
  until you run "git help pull" and go WHAAA?