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

The largest Git repo

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

411–416 of 416 posts

Re: The largest Git repo

#411

Post by cormacrelf »

eihakker wrote: post #410
cormacrelf wrote: post #336

Earlier quoted context omitted.

There's nothing stopping you from doing merges instead of rebases. * latest feature commit #3 (feature) * merge /| * | more master commits you wanted to include (master) | * feature commit #2 | * merge |/| * | master commits you wanted to include | * feature commit #1 |/ * original master tip * master history... Then, when you're done with feature, if you really care about clean history, just rebase the entire histor…

*latest feature c *merge /| * |more master comm. | feature commit #: | merge |/| * |master commits y | feature commit # |/ original master * master history ..

maybe try that again keeping 4 spaces before each line?

Re: The largest Git repo

#412

Post by luckydude »

cryptonector wrote: post #407
luckydude wrote: post #404

Earlier quoted context omitted.

Nope, you want what I called the event stack. It lets you have your cake and eat it too. The event stack is a record of every tip that was ever present in this repo other than unpushed commits. You were at cset 1234, you pull in 25 csets, the event stack has two events, 1 which points to 1234 and 2 which points at the tip after the pull. You commit "wacked the crap out of it", then commit "fixed typo", then commit "a…

Yes, I've been asking for branch history (the reflog provides some, but it's insufficient because it's not shared in any way). Even with this, I'd want to rebase away "fixed typo" prior to pushing, and more, I'd want to: - organize commits into logical chunks so that they might be cherry-picked (in the literal sense, not just the VCS sense) into maintenance release branches - organize commits as the upstream prefers…

So the current BK doesn't really have branches, it has the model that if you want to branch you clone, each clone is a branch.

Which begs the question "how do you do dev vs stable branches?" And the answer is that we have a central clone called "dev" and a central clone called "stable". In our case we have work:/home/bk/stable and work:/home/bk/dev. User repos are in work:/home/bk/$USER/dev-feature1 and work:/home/bk/$USER/stable-bugfix123.

We run a bkd in work:/home so our urls are

    bk://work/dev
    bk://work/$USER/dev-feature1
BK has a concept of a level - you can't push from a higher level to a lower level. So stable would be level 1, dev would be level 2. Levels propogate on clone so when you do

    bk clone bk://work/dev dev-feature2
and then try and do

    bk push bk://work/stable
it will tell you that you can't push to a lower level. This prevents backflow of all the new feature work into your stable tree.

The model works well until you have huge (like 10GB and bigger) repos. At that point you really want branches because you don't want to clone 10GB to do a bugfix.

Though we addressed that problem, to some extent, by having nested collections (think submodules that actually support all workflows, unlike git, they are submodules that work). So you can clone the subset you need to do your bugfix.

But yeah, there are cases where "a branch is a clone" just doesn't scale, no question. But where it does work it's a super simple and pleasant model

Re: The largest Git repo

#413

Post by luckydude »

cryptonector wrote: post #409
luckydude wrote: post #403

Earlier quoted context omitted.

I'm the guy who started this DAG model (also at Sun with NSElite and then later with BitKeeper). I agree that rebase == centralized. It's a math thing. If you rebase and someone has a clone of your work prior to the rebase chaos happens when they come together. So you have to enforce a centralized flow to make it work in all cases. It's pretty much provable as in a math proof.

Not true! At Sun we did this with project gates regularly. The way it works (as I've described several times in this thread now) is that you rebase --onto. That is, you use a tag for the pre-rebase project upstream to find the merge base for your branch, then cherry-pick your commits (i.e., all local commits after the merge base) onto the post-rebase project upstream. Now, you don't want to do this with the ultimate…

I get that you can work around the problems, you don't seem to get that from a math point of view, rebase forces either

a) a centralized model

or

b) you have to throw away any work based on the dag before the rebase

or)

c) you have the history in the graph twice (which causes no end of problems).

(a) is the math way, (b) and (c) are ad-hoc hacks. You are well into the ad-hoc hacks, you've found a way to make it work but it includes "don't do that" warnings to users. My experience is that you don't want to have work flows that include "don't do that". Users will do that.

Re: The largest Git repo

#414

Post by _asummers »

jjawssd wrote: post #408
_asummers wrote: post #396

Earlier quoted context omitted.

We version each of our individual resources. so a /v1/user might have many /v3/post . Seems to work for us as a smaller engineering team.

A better approach would be to alias /v3/user to /v1/user until there is a breaking change needed in the v3 code tier.

On a rapidly developing API, that would be way too much churn on our front end. For an externally facing API, I completely agree.

Re: The largest Git repo

#415

Post by nthcolumn »

BenjiWiebe wrote: post #330
nthcolumn wrote: post #226

Linus Torvalds rocks. Windows sucks. Subversion was crap so he just made git instead. git beat out svn, TFS and all that other crap legions of overpaid engineers came up with (or what they didn't get source control???) because unix design philosophy and therein lies the lesson still unlearned for they hath loaded all their bloat into one repo. Windows. It sucks and it will forever suck because it sucks by design. Bil…

Sadly we will have to quit blaming Bill Gates. I doubt he makes very many design decisions any more. :)

If he had only listened to me and re-released Xenix open source with a decent WM we could have avoided all this unpleasantness but no, he had to listen to Monkeyboy. :/

Re: The largest Git repo

#416

Post by emmelaich »

cryptonector wrote: post #329
emmelaich wrote: post #298

Earlier quoted context omitted.

Are you saying that you use Git instead of Mercurial these days? Not necessarily implied by you; just checking.

Me personally? Yes, I use git whenever I can. I still have to use Mercurial for some things. I don't know what Oracle does nowadays with the gates that make up Solaris. My guess is that they still have a hodge podge, with some gates using git, some Mercurial, and some Teamware still. But that's just a guess. For all I know they may have done what Microsoft did and gone with a single repo for the whole thing.

This is old but I meant Sun/Oracle/Java.

I remember watching the process to choose a new VCS. Mercurial is a fine choice but not the best choice. Even over the duration of the decision process the world was clearly moving overwhelmingly to Git.

Post reply on HN