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

81–90 of 93 posts

Re: Git 2.0 release notes

#81

Post by beagle3 »

stormbrew wrote: post #18
beagle3 wrote: post #9

Earlier quoted context omitted.

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.

If you use git-subtree in the mode that doesn't flatten the original tree it does not, afaik, modify any commits on either side. The original tree, as imported, and the tree being imported to, are both parents of the post-subtree tree with their original SHAs.

Wasn't aware of that. That's kind of awesome.

You seem to be very knowledgeable about subtree, so I'll ask a question you can hopefully answer:

I have multiple repositories each having 100,000-500,000 files, all relating to the same project. The reason I broke them up to multiple projects is that the git index doesn't handle millions of files all that well (e.g. index gets rewritten on every modification). Would subtree help me here in any way?

Of course, this is not a usual way to use git, and Facebook opted for switching to Mercurial when faced with a similar problem (though an order of magnitude or two larger, I'm sure).

submodules work for me now, but they are very clunky -- but the reason I didn't even try switching was the crypto signing of commits, which is apparently not a problem. Would subtrees help me with the scale as well in any way?

Re: Git 2.0 release notes

#83

Post by stormbrew »

beagle3 wrote: post #81
stormbrew wrote: post #18

Earlier quoted context omitted.

If you use git-subtree in the mode that doesn't flatten the original tree it does not, afaik, modify any commits on either side. The original tree, as imported, and the tree being imported to, are both parents of the post-subtree tree with their original SHAs.

Wasn't aware of that. That's kind of awesome. You seem to be very knowledgeable about subtree, so I'll ask a question you can hopefully answer: I have multiple repositories each having 100,000-500,000 files, all relating to the same project. The reason I broke them up to multiple projects is that the git index doesn't handle millions of files all that well (e.g. index gets rewritten on every modification). Would subt…

No, I don't think subtrees can really help you with this unfortunately. At least not directly. Using the flattened mode might help, but then you'd be back to your problem with signing them. The subtree merge commit does record the original SHA, so I suppose you could verify as a separate step if you needed to that that merge commit is indeed the result of a correctly signed SHA somehow.

But I think for your use case you're probably stuck with submodules.

Re: Git 2.0 release notes

#84

Post by davvid »

Aissen wrote: post #17
nbouscal wrote: post #15

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.

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.

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

Re: Git 2.0 release notes

#85

Post by sanderjd »

bronson wrote: post #67
sanderjd wrote: post #52

Earlier quoted context omitted.

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?

Yep, I think a good way to put it is that subtrees are (or feel like) far more "first class" - you can do all the normal stuff with them.

Re: Git 2.0 release notes

#86

Post by sampo »

Skinney wrote: post #58
sampo wrote: post #43

Earlier quoted context omitted.

> In mercurial you have Branches and Bookmarks. In git you just have branches. I think git branches correspond more to hg bookmarks, than to hg named branches.

Isn't the only real difference that hg branches are constant, while bookmarks are temporary?

Yeah, in hg named branches the branch name is forever logged as part of the commit. Hg bookmarks and git branches are just pointers to the most recent commit.

Re: Git 2.0 release notes

#87

Post by penguindev »

beagle3 wrote: post #82
stefan_kendall3 wrote: post #25

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

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

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

Re: Git 2.0 release notes

#88

Post by penguindev »

stefan_kendall3 wrote: post #72
penguindev wrote: post #66

Earlier quoted context omitted.

... due to force pushing multiple branches?

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.

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.

Re: Git 2.0 release notes

#89

Post by beagle3 »

penguindev wrote: post #87
beagle3 wrote: post #82

Earlier quoted context omitted.

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

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

That looks so wrong to me. It says everywhere in the docs "never rebase something that's been published" and it says so for a reason.

The fact that git lets you shoot yourself in the foot doesn't mean you should, definitely not incorporate this into working procedures.

If it's a private feature branch, don't make it public (pushing would still back it up on the server, though you'd have to know the sha1 to fixed it). If it's public, don't rebase it.

Re: Git 2.0 release notes

#90

Post by mikeklaas »

stefan_kendall3 wrote: post #72
penguindev wrote: post #66

Earlier quoted context omitted.

... due to force pushing multiple branches?

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.

`push -f` and `workflow` should never be in the same sentence.
Post reply on HN