10 ms·

Git 2.0 release notes

230 points by redox_ 13y ago

rplnt 13y ago
Is this released already or are those just preliminary release notes?
- chiefsucker 13y ago
  The current version is still 1.9, but it shouldn’t take long for 2.0 to be the official stable release.
nbouscal 13y ago
Minor feature that's really nice: the pull.ff config setting. I had made an alias for doing that manually, now I can start actually using git pull again.
- Aissen 13y ago
  Haha, me too, my lovely "git pfo" will have to go… Maybe. The problem with git is that new options aren't simply ignored by old git versions, meaning that if you synchronize your gitconfig as part of your dotfiles, then the machines that have old git versions will start spitting error messages at every command for options specific to new versions. I learned that painfully with push.default=simple.
  - davvid 13y ago
    For `push.default`, older versions understood `push.default` but only later was the `simple` mode added. For `pull.ff`, old versions will simply ignore the setting. I know because I wrote the patch ;-)
stormbrew 13y ago
I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.
- aktau 13y ago
  I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".
  - etherealG 13y ago
    Any chance you could outline the downside of subtree? I've always thought it was better in every way.
    - sqs 13y ago
      Submodule can be used when you want to nest a private repository inside of a public one. Only authorized users will be able to fetch from the submodule repository. This can be useful in some cases, such as storing private keys in an otherwise public project. Also, if you have a very large submodule repository, it won't inflate the size of the repository that contains it.
      - stormbrew 13y ago
        git-subtree can flatten the other tree into a single commit while preserving the ability to use all its other functionality, which is actually probably a space-saving measure compared to submodules when you consider that anyone who uses your repo probably needs to get the submodule anyway, and that means downloading that other giant repo in its entirety vs. downloading a flattened copy of it.
        stingraycharles 13y ago
        So if I understand this correctly, it is more of a convenient way to copy (and update) another repository into another one, instead of being a reference to another repository. To respond to the comment about this being useful for private keys: if this is the case, does this also mean unauthorized users will not be able to checkout the submodule at all? Or will they just get a copy of the files (which would not make sense with private keys).
anton_gogolev 13y ago
Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where
- davidw 13y ago
  There was a thing going around twitter lately: > If ping was designed by the git people: net-ping host --no=dns,bind --proto=TCP,rfc:492 eth0@ipv4::http://1.0.0.127.IN http://1.0.0.127.IN -ADDR.ARPA --stats -v
  - beaumartinez 13y ago
    Attribution— https://twitter.com/gitHater/status/169978106227068928 https://twitter.com/gitHater/status/169978106227068928
  - rbonvall 13y ago
    I think it would be git checkout --ping (Checkout already does too much; one more doesn't hurt).
  - sanderjd 13y ago
    That honestly doesn't have the truth ring of good satire for me... It seems to be making fun of the lack of sane defaults in git (maybe?), but if anything, git seems too focused on mysterious implicit configuration-controlled behavior, over explicit control. Edit: Ah, hmm, maybe the satire is more along the lines of "a single command does too much stuff", which does ring true for commands like `checkout` and `reset`.
- jgraham 13y ago
  Comparing hg branches to git branches in this context isn't super-useful; the right comparison is to hg bookmarks. In this case the semantics seem to be (based on reading the documentation so I might be wrong): hg push [dest] -- Push all local bookmarks that match a remote bookmark hg push -B [dest] -- Push a specific local bookmark to a remote To me those semantics don't seem particularly simple or flexible. In fact it seems quite like the semantics git is moving away from but with the restriction that local names and remote names always have to match, which means that you have to be very careful naming your local bookmarks to avoid clashes.
stefan_kendall3 13y ago
"git push -f" will no longer ruin days (as badly)
- penguindev 13y ago
  ... due to force pushing multiple branches?
  - glasser 13y ago
    Exactly. Doing that by mistake (and then being taught to set `push.default` to upstream or simple) has been a rite of passage for engineers at my company.
    - markmark 13y ago
      I never quite understood why the default was what it was. I can count the times I've wanted to push all branches at once on no hands. But maybe that's just my work flow.
  - stefan_kendall3 13y ago
    I've seen someone do it. If your workflow is 'git push -f feature' after rebasing, instead of 'git push feature -f', you can tap enter and break the world.
    - penguindev 13y ago
      It really blows my mind that you say those two aren't equivalent. I now must read the man pages... Edit did you mean to say (plus)feature or is something ruining the formatting? That seems to be how to specify only one branch. Yuck. I'm lucky I haven't run into this, I guess, because I set my push default to simple a long time ago, so long ago I can't even remember why.
      - stefan_kendall3 13y ago
        The two are equivalent if you type them in full, but if you stop one before typing the feature branch name, you've broken everything. git push -f (enter) => Death to all branches. git push feature -f => Can only ever force push the feature branch No matter when you press enter in the second line, intentionally or accidentally, you can't break all branches.
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
lobster_johnson 13y ago
I like the "add" is more inclusive by default. But does this mean that "add -p" also can add untracked files? (If not, it seems inconsistent to me.)
- doidydoidy 13y ago
  Like it says in the man page, git add -p "effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand". Interactive mode does support adding untracked files.
  - lobster_johnson 13y ago
    Not what I'm asking. "add -p" will offer deletions, but it should also offer to add untracked files, essentially showing a diff with all lines added (with an empty file as the base). "add -p --all some_untracked_file" does nothing, "--interactive" does something completely different; a menu system, not a "yes/no/etc." patch prompt.
eslaught 13y ago
Is there any intention among the Git developers to ever make --recursive a default option for git clone? (This is an option that causes git clone to recursively clone any submodules as well as the top-level repo.) Sure, arguably there are fundamental issues with submodules that you won't ever solve, and some people might prefer subtree to become the default. (I won't get into that argument here as there is another thread addressing that topic.) But the fact still stands that a lot of the ugliness of submodules comes from the fact that the UI forces users to learn a whole extra set of commands, while the regular commands are largely oblivious to the existence of submodule. If I make a Git repo with submodules, I can't just pass a link to my Git-novice friends and have them clone it, because the UI for submodules is separate from the main Git UI. Arguably, for users who don't need to actually touch the submodule, the fact that the submodule is there should be invisible from the perspective of the UI. Although Git has been gradually getting closer to this being true, it is not currently the case (clone being an example of one command which is not aware of submodules by default).

230 points by redox_ 13y ago

rplnt 13y ago

Is this released already or are those just preliminary release notes?

chiefsucker 13y ago
The current version is still 1.9, but it shouldn’t take long for 2.0 to be the official stable release.

nbouscal 13y ago

Minor feature that's really nice: the pull.ff config setting. I had made an alias for doing that manually, now I can start actually using git pull again.

Aissen 13y ago
Haha, me too, my lovely "git pfo" will have to go… Maybe. The problem with git is that new options aren't simply ignored by old git versions, meaning that if you synchronize your gitconfig as part of your dotfiles, then the machines that have old git versions will start spitting error messages at every command for options specific to new versions. I learned that painfully with push.default=simple.
- davvid 13y ago
  For `push.default`, older versions understood `push.default` but only later was the `simple` mode added. For `pull.ff`, old versions will simply ignore the setting. I know because I wrote the patch ;-)

stormbrew 13y ago

I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.

aktau 13y ago
I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".
- etherealG 13y ago
  Any chance you could outline the downside of subtree? I've always thought it was better in every way.
  - sqs 13y ago
    Submodule can be used when you want to nest a private repository inside of a public one. Only authorized users will be able to fetch from the submodule repository. This can be useful in some cases, such as storing private keys in an otherwise public project. Also, if you have a very large submodule repository, it won't inflate the size of the repository that contains it.
    - stormbrew 13y ago
      git-subtree can flatten the other tree into a single commit while preserving the ability to use all its other functionality, which is actually probably a space-saving measure compared to submodules when you consider that anyone who uses your repo probably needs to get the submodule anyway, and that means downloading that other giant repo in its entirety vs. downloading a flattened copy of it.
      - stingraycharles 13y ago
        So if I understand this correctly, it is more of a convenient way to copy (and update) another repository into another one, instead of being a reference to another repository. To respond to the comment about this being useful for private keys: if this is the case, does this also mean unauthorized users will not be able to checkout the submodule at all? Or will they just get a copy of the files (which would not make sense with private keys).

anton_gogolev 13y ago

Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where

davidw 13y ago
There was a thing going around twitter lately: > If ping was designed by the git people: net-ping host --no=dns,bind --proto=TCP,rfc:492 eth0@ipv4::http://1.0.0.127.IN http://1.0.0.127.IN -ADDR.ARPA --stats -v
- beaumartinez 13y ago
  Attribution— https://twitter.com/gitHater/status/169978106227068928 https://twitter.com/gitHater/status/169978106227068928
- rbonvall 13y ago
  I think it would be git checkout --ping (Checkout already does too much; one more doesn't hurt).
- sanderjd 13y ago
  That honestly doesn't have the truth ring of good satire for me... It seems to be making fun of the lack of sane defaults in git (maybe?), but if anything, git seems too focused on mysterious implicit configuration-controlled behavior, over explicit control. Edit: Ah, hmm, maybe the satire is more along the lines of "a single command does too much stuff", which does ring true for commands like `checkout` and `reset`.
jgraham 13y ago
Comparing hg branches to git branches in this context isn't super-useful; the right comparison is to hg bookmarks. In this case the semantics seem to be (based on reading the documentation so I might be wrong): hg push [dest] -- Push all local bookmarks that match a remote bookmark hg push -B [dest] -- Push a specific local bookmark to a remote To me those semantics don't seem particularly simple or flexible. In fact it seems quite like the semantics git is moving away from but with the restriction that local names and remote names always have to match, which means that you have to be very careful naming your local bookmarks to avoid clashes.

stefan_kendall3 13y ago

"git push -f" will no longer ruin days (as badly)

penguindev 13y ago
... due to force pushing multiple branches?
- glasser 13y ago
  Exactly. Doing that by mistake (and then being taught to set `push.default` to upstream or simple) has been a rite of passage for engineers at my company.
  - markmark 13y ago
    I never quite understood why the default was what it was. I can count the times I've wanted to push all branches at once on no hands. But maybe that's just my work flow.
- stefan_kendall3 13y ago
  I've seen someone do it. If your workflow is 'git push -f feature' after rebasing, instead of 'git push feature -f', you can tap enter and break the world.
  - penguindev 13y ago
    It really blows my mind that you say those two aren't equivalent. I now must read the man pages... Edit did you mean to say (plus)feature or is something ruining the formatting? That seems to be how to specify only one branch. Yuck. I'm lucky I haven't run into this, I guess, because I set my push default to simple a long time ago, so long ago I can't even remember why.
    - stefan_kendall3 13y ago
      The two are equivalent if you type them in full, but if you stop one before typing the feature branch name, you've broken everything. git push -f (enter) => Death to all branches. git push feature -f => Can only ever force push the feature branch No matter when you press enter in the second line, intentionally or accidentally, you can't break all branches.

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]

lobster_johnson 13y ago

I like the "add" is more inclusive by default. But does this mean that "add -p" also can add untracked files? (If not, it seems inconsistent to me.)

doidydoidy 13y ago
Like it says in the man page, git add -p "effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand". Interactive mode does support adding untracked files.
- lobster_johnson 13y ago
  Not what I'm asking. "add -p" will offer deletions, but it should also offer to add untracked files, essentially showing a diff with all lines added (with an empty file as the base). "add -p --all some_untracked_file" does nothing, "--interactive" does something completely different; a menu system, not a "yes/no/etc." patch prompt.

eslaught 13y ago

Is there any intention among the Git developers to ever make --recursive a default option for git clone? (This is an option that causes git clone to recursively clone any submodules as well as the top-level repo.) Sure, arguably there are fundamental issues with submodules that you won't ever solve, and some people might prefer subtree to become the default. (I won't get into that argument here as there is another thread addressing that topic.) But the fact still stands that a lot of the ugliness of submodules comes from the fact that the UI forces users to learn a whole extra set of commands, while the regular commands are largely oblivious to the existence of submodule. If I make a Git repo with submodules, I can't just pass a link to my Git-novice friends and have them clone it, because the UI for submodules is separate from the main Git UI. Arguably, for users who don't need to actually touch the submodule, the fact that the submodule is there should be invisible from the perspective of the UI. Although Git has been gradually getting closer to this being true, it is not currently the case (clone being an example of one command which is not aware of submodules by default).