Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git 2.0 release notes

git.kernel.org

Post reply on HN
Print view View original

1–10 of 93 posts

Re: Git 2.0 release notes

#2

Post by stormbrew »

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.

Re: Git 2.0 release notes

#3

Post by aktau »

stormbrew wrote: post #2

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.

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

Re: Git 2.0 release notes

#4

Post by etherealG »

aktau wrote: post #3
stormbrew wrote: post #2

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.

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

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

Re: Git 2.0 release notes

#5

Post by sqs »

etherealG wrote: post #4
aktau wrote: post #3

Earlier quoted context omitted.

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

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

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.

Re: Git 2.0 release notes

#6

Post by bru »

aktau wrote: post #3
stormbrew wrote: post #2

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.

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

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

Re: Git 2.0 release notes

#7

Post by anton_gogolev »

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

Re: Git 2.0 release notes

#8

Post by davidw »

anton_gogolev wrote: post #7

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

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

Re: Git 2.0 release notes

#9

Post by beagle3 »

etherealG wrote: post #4
aktau wrote: post #3

Earlier quoted context omitted.

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

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

Subtree operations modify commits (and trees). As a result, cryptographically signing or validating a subtree operation does not extend to an independent module, and vice versa. If you care about these things, it's a big deal.

Re: Git 2.0 release notes

#10

Post by jgraham »

anton_gogolev wrote: post #7

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

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.
Post reply on HN