Git 2.0 release notes

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/2.0.0.txt

by redox_ • 12 years ago

230 90 12 years ago

git.kernel.org

stormbrew6• 12 years 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.

aktau2• 12 years 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• 12 years ago

Any chance you could outline the downside of subtree? I've always thought it was better in every way.

bru• 12 years ago

I've noticed that most devs seem to have strong opinions one way or another.

I've personally noticed that most devs don't have an opinion either way since they don't use subtrees nor submodules.

I don't know what subtrees offer but using submodules has been very pleasant once you know how they work. For example if you version control your .vim I think that adding submodules for extensions is way better than cloning them inside your .vim.

I look forward to having the opportunity to use subtrees.

ingy• 12 years ago

You may want to take a look at https://github.com/ingydotnet/git-subrepo#readme (and join #git-commands on freenode).

rip747• 12 years ago

how close is git-subtree to svn-externals? I've always had people complain about moving from svn to git because there wasn't a feature like svn-externals. git-submodules obviously didn't cut it.

TheHippo• 12 years ago

In my opinion it's way better then submodule or svn-externals. Basically it allows you to take an specific folder from your repository and push only this folder to an additional repository. This repository could be included into another repository which makes sharing code between repositories very easy while keeping history in each of them and the history for this special folder in an extra repository.

stormbrew6• 12 years ago

It's kind of difficult to compare. I actually think of submodules as being much closer to svn externals in nature, just very poorly integrated (I'm not sure anyone on the git core team actually uses submodules, in things I've read as justification for its poor implementation from core team members it seems like they only added it as a checkbox feature).

Subtrees are quite different from either. They make the imported repository literally a part of the commit graph of the parent tree through a subtree-merge-commit. It then does some extra work to help you bring in new changes or export new changes back.

I think it's a better approach than either, but it's also not exactly the same thing, basically.

anton_gogolev7• 12 years 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• 12 years 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 -ADDR.ARPA --stats -v

beaumartinez• 12 years ago

Attribution—

https://twitter.com/gitHater/status/169978106227068928

rbonvall• 12 years ago

I think it would be

    git checkout --ping

(Checkout already does too much; one more doesn't hurt).

sanderjd3• 12 years 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`.

jgraham2• 12 years 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.

trurl42• 12 years ago

I guess 'simple' means "don't try to be too smart".

Pushing only the current branch by default is a good thing, I think. If you are using a more centralized setup you can change the configuration of push.default to 'matching'.

exDM692• 12 years ago

Is it just me or "simple semantics" is not at all simple?

It's just you.

It's about time we'd put "hg vs. git" to the category of flamebait topics (similar to "emacs vs. vi" etc) that should be avoided. Every time there's a git topic, someone comes and derails the whole discussion with a not-quite-apt comparison with hg.

AFAIK, there are decent two-way conversion tools so you can use hg with a git repo and vice versa. There should be no need to argue because you can pick the one you like and use it.

simias• 12 years ago

So comparing two competing tools is flamebait nowadays?

I think the OP makes a valid and argumented point.

VeejayRampay• 12 years ago

Also, hasn't git won already? I mean, I'm sure Mercurial is a great tool and all, but git is massive and widespread now, there's no going back and sharing of the pie until a new generation of VCS that completely changes the game emerges I think.

krig4• 12 years ago

When you say "the currently checked out branch", do you mean the current branch, bookmark, head, local branch or mutable branch? Or maybe you are referring to the current phase, or a secret changeset?

"Mercurial is so much simpler than git" is only true for one reason: You prefer mercurial and dislike git, and so you look for flaws in git while glossing over flaws in mercurial.

egork8n• 12 years ago

You just need to visualize the tree, and that's it. `hg push -r .` will push checked out changeset and all its ancestors.

Mercurial tracks changesets. Git guys are inventing all kings of weird entities. Local branch? Mutable branch? Do these kind of things have separate sets of semantics in the git world?

In mercurial, branch is just a constant name for a group of changesets. Bookmark is just a temporary pointer to the changeset. Head is a changeset (that have no successors). Phase is information about whether it is safe to modify changeset. Mercurial is indeed a lot simpler.

anton_gogolev7• 12 years ago

Or maybe it is Git that has introduced all kinds of crazy concepts that you're now struggling to keep in mind? Local branches? Remote tracking branches? Mutable branches? Really?

nnethercote• 12 years ago

http://jordi.inversethought.com/blog/on-gitology/ is a good explanation of how git is overly complex.

js2• 12 years ago

Perhaps "dwim" would be a better description of simple, but it arose from much feedback and debate on the git mailing list. Its behavior is now what it is believed most git newcomers expect.

marincounty• 12 years ago

No it's not you. It's overly complicated. This is what has always irked me about computing--making something seem more difficult than needed. I'm not asking for for an Apple solution, just cut the bull shit--high brow--If you don't know GIT you shouldn't be programming. It's a repository. I shouldn't need a git pocket guide. I want things fast and efficient. I don't like to spend daylight hours figuring out things; life is too short. In reality, I don't even like sitting in front of a computing devise, but society now requires it.

bronson3• 12 years ago

Just curious, where is this highbrow "if you don't know GIT you shouldn't be programming" bullshit you speak of?

rplnt• 12 years ago

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

chiefsucker• 12 years ago

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

nbouscal• 12 years 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• 12 years 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• 12 years 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 ;-)

stefan_kendall33• 12 years ago

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

penguindev5• 12 years ago

... due to force pushing multiple branches?

glasser• 12 years 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.

stefan_kendall33• 12 years 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.

acchow• 12 years ago

Possibly the most confusing default in git. My gitconfig has:

  [push]
    config = default
        default = tracking

I once made a virtual machine and didn't pull in my usual .gitconfig. It ruined my day.

beagle34• 12 years ago

I have never had the need to force a push. What are the circumstances that would require it?

penguindev5• 12 years ago

you have a private feature branch on git hub, clean it up via rebase (or just rebase to latest master) before review, and you need to force push it.

on long running features, you 1. want to save your state off of your laptop and 2. keep it clean for your own review and for others' review. thus, force push is required, otherwise you'd have to keep making new revs of your branch (branch named joeblow/my_feature_rev_4).

lobster_johnson2• 12 years 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• 12 years 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_johnson2• 12 years 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• 12 years 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).

Git 2.0 release notes

Related Stories