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

61–70 of 93 posts

Re: Git 2.0 release notes

#61

Post by acdha »

kyrra wrote: post #47
acdha wrote: post #42

Earlier quoted context omitted.

For years the Hg community proclaimed it was the answer to git rebase. Might be time for a concerted doc push to get those references updated with pointers to the rebase extension instead.

Because it was the answer originally (it's wiki page appeared in 2005, rebase appeared in 2008). Then rebase became the better answer. What proclaimed answer are you referring to here? On their GitConcepts[0] page, it says "hg rebase" or "hg histedit" should be used to do "git rebase" type operations. The only time they recommend MQ is if you want the index or the "git am" type command. And as anton_gogolev mentioned…

> What proclaimed answer are you referring to here?

You answered that in your first paragraph: for many years, the first time people looked at Mercurial the answer for that class of problems was mq. The problem now is that it's still easy to find stale internal documentation, old blog posts, etc. which haven't been updated with the new recommendations. I thought that it might be worth having a small campaign to encourage people to update old wikis, contact blog authors, etc. when they find those recommendations and suggest a simple “this is no longer recommended – see …” update.

Re: Git 2.0 release notes

#63

Post by stormbrew »

rip747 wrote: post #55
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.

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.

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.

Re: Git 2.0 release notes

#64

Post by stormbrew »

sqs wrote: post #5
etherealG wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Git 2.0 release notes

#65

Post by stingraycharles »

stormbrew wrote: post #64
sqs wrote: post #5

Earlier quoted context omitted.

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.

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.

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

Re: Git 2.0 release notes

#67

Post by bronson »

sanderjd wrote: post #52
bru wrote: post #6

Earlier quoted context omitted.

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

Subtrees interact with history in a much more obvious, configurable, and automatic way. The most obvious win is never having to run `git submodule update`. The better control over history is the bigger, but less obvious win. Since you have some experience using submodules for your .vim, maybe try switching to subtrees and see what you think. I like the Atlassian blog post[0] about them for getting started. [0]: http:…

For me the the most obvious win is still being able to merge, move forward in time, move backward in time, rebase, etc. Everything that makes Git great.

Once you have submodules in your repo, all that becomes heinous. PLUS everything you mentioned...

Sure, if you don't use those features, then submodules would probably work fine. But then why not just use Dropbox?

Re: Git 2.0 release notes

#68

Post by bronson »

anton_gogolev wrote: post #50
matthewmacleod wrote: post #48

Earlier quoted context omitted.

I'm familiar with the history of git. I'm also aware that nothing you said actually dealt with the fact that git is not unusable. In fact, it's objectively pretty good—if it weren't, we'd all still be using SVN. What you seem to be saying is that you prefer the UX of Mercurial. Cool, that's fine - but I'd be keen for people to invest their time in improving the experience of using git, rather than bellyaching about p…

There are no objective criteria to measure usability, so Git cannot possibly be "objectively pretty good", sorry. Again, popularity has nothing to do with merit. It's a pure happenstance that Git was chosen over Mercurial for kernel development, and it all went from there. The UX of Git cannot possibly be improved in the foreseeable future as it will be a _massive_ pile of breaking changes with people moaning all ove…

Git is not as bad as you claim, and Hg is not as good as you claim. Yes, I have used both.

If you're looking to derail this post and do some trolling, then congratulations. You're off to a great start.

Re: Git 2.0 release notes

#69

Post by glasser »

penguindev wrote: post #66
stefan_kendall3 wrote: post #25

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

... due to force pushing multiple branches?

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.

Re: Git 2.0 release notes

#70

Post by Tyr42 »

stingraycharles wrote: post #65
stormbrew wrote: post #64

Earlier quoted context omitted.

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.

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 s…

When you git clone a repository with a submodule, before you call git submodule sync/update and all that jazz, you just have an empty directory where the submodule should be.
Post reply on HN