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

381–390 of 416 posts

Re: The largest Git repo

#381

Post by cryptonector »

rdubz wrote: post #369
cryptonector wrote: post #326

Earlier quoted context omitted.

Well, git rerere helps here, though, honestly, this never happens to me even when I have 20 commits. Also, this is what you want, as it makes your commits easier to understand by others. Otherwise, with thousands of developers your merge graph is going to be a pile of incomprehensible spaghetti, and good luck cherry-picking commits into old release patch branches! Ah, right, that's another reason to rebase: because y…

rebase : centralized repo :: merge : decentralized repo rebase : linked-list :: merge : DAG If the work/repo is truly distributed and there isn't a single permanently-authoritative repo, a "clean, linear" history is nonsensical to even try to reason about. In all cases it is a crutch: useful (and nice, and sufficient!) in simple settings, but restricting/misleading in more complex ones (to the point of causing many d…

Also, it's harder to grok merge history because we humans have a hard time with complexity, and merge history in a system with thousands of developers and multiple upstreams can get insanely complex. The only way to cut through that complexity is to make sure that each upstream ends up with linear history -- that is: to rebase downstreams.

Re: The largest Git repo

#382

Post by aeorgnoieang »

wbl wrote: post #340
rak00n wrote: post #320

Earlier quoted context omitted.

I felt like that when I first saw golang and how you can effortlessly use any repo from anywhere.

As the joke goes, Go assumes all your code lives in one place controlled by a harmonious organization. Rust assumes your dependencies are trying to kill you. This says a lot about the people who came up with each one.

> Rust assumes your dependencies are trying to kill you.

Would you mind unpacking this? I'm intrigued.

Re: The largest Git repo

#383

Post by dom0 »

aeorgnoieang wrote: post #382
wbl wrote: post #340

Earlier quoted context omitted.

As the joke goes, Go assumes all your code lives in one place controlled by a harmonious organization. Rust assumes your dependencies are trying to kill you. This says a lot about the people who came up with each one.

> Rust assumes your dependencies are trying to kill you. Would you mind unpacking this? I'm intrigued.

Cargo.lock for applications freezes the entire dependency graph incl. checksums of everything, for example.

Re: The largest Git repo

#384

Post by amptorn »

a-priori wrote: post #368
amptorn wrote: post #130

Earlier quoted context omitted.

> Why split it into separate modules? Well, because of the unbelievable amount of engineering work involved in trying to get Git to operate at such insane scale? To say nothing of the risk involved in the alternative. This project in particular could easily have been a catastrophe.

Microsoft has about 50k developers. When you're dealing with an engineering organization of this size, you're looking at a run rate of $5B a year, or about $20M a day. It's a no-brainer to spend tens or even hundreds of millions of dollars on projects like this if you're going to get even a few percentage points of productivity. It can be hard to understand this as an individual engineer, but large tech companies are…

You haven't said anything at all about the risk.

Re: The largest Git repo

#385

Post by Peaker »

eridius wrote: post #176
Peaker wrote: post #167

Earlier quoted context omitted.

When you have that many conflicts, it's often due to massive renames, or just code moves. If you use git-mediate[1], you can re-apply those massive changes on the conflicted state, run git-mediate - and the conflicts get resolved. For example: if you have 300 conflicts due to some massive rename, you can type in: git-search-replace.py[2] -f oldGlobalName///newGlobalName git-mediate -d Succcessfully resolved 377 confl…

I just looked at git-mediate and I'm very confused. It appears that all it does is remove the conflict markers from the file after you've already manually fixed the conflict. Except you need to do more work than normal, because you need to apply one of the changes not only to the other branch's version but also to the base. What am I missing here, why would I actually want to use git-mediate when I'm already doing al…

That's why I showed an example of a rename. You write "manually fixed the conflict", where do you see that in the rename example?

You just re-apply either side of the changes in the conflict (Base->A, or Base->B) and the conflict is then detected as resolved. Reapplying (e.g: via automated rename) is much easier than what people typically mean by "manually resolving the conflict".

Also, as a pretty big productivity boost, it prints the conflicts in a way that lets many editors (sublime, emacs, etc) directly jump to conflicts, do the "git add" for you, etc. This converts your everyday editor into a powerful conflict resolution tool. Using the editing capabilities in most merge tools is tedious.

Re: The largest Git repo

#386

Post by bobsam »

hinkley wrote: post #311
pmontra wrote: post #263

Earlier quoted context omitted.

Git has submodules too and teams usually have access control on the main server used for sharing commits.

git submodules aren't seemless. None of the alternatives appear to be any better. A halfassed solution is no solution at all.

What's wrong with git submodules?

Re: The largest Git repo

#387

Post by a-priori »

amptorn wrote: post #384
a-priori wrote: post #368

Earlier quoted context omitted.

Microsoft has about 50k developers. When you're dealing with an engineering organization of this size, you're looking at a run rate of $5B a year, or about $20M a day. It's a no-brainer to spend tens or even hundreds of millions of dollars on projects like this if you're going to get even a few percentage points of productivity. It can be hard to understand this as an individual engineer, but large tech companies are…

You haven't said anything at all about the risk.

If there's one thing large organizations are good at, it's managing risk. And if you read their post, they've done this.

They're running both source control systems in parallel, switching developers in blocks, and monitoring commit activity and feedback to watch for major issues. In the worst case, if GVFS failed or developers hated it, they could roll back to their old system.

Again, to my point above: there's a cost to doing this but it's negligible for very large organizations like Microsoft.

Re: The largest Git repo

#388

Post by cryptonector »

cryptonector wrote: post #194

At Sun Microsystems, Inc., (RIP) we have many "gates" (repos) that made up Solaris. Cross-gate development was somewhat more involved, but still not bad. Basically: you installed the latest build of all of Solaris, then updated the bits from your clones of the gates in question. Still, a single repo is great if it can scale, and GVFS sounds great! But that's not what I came in to say. I came in to describe the rebase…

A trip through "git rebase" search results at HN sure is cringe-inducing. So many people fail to get it.

Re: The largest Git repo

#389

Post by cyphar »

bischofs wrote: post #174

Any word on open sourcing parts of the windows OS now that MS is seeing the light? The head guys have to see the benefits by now. It says something that MS chose Git over anything proprietary that they developed.

If you look at how long it took for Sun to make Solaris free software (and even then it wasn't truly free in some cases) I doubt Microsoft would ever consider spending that much time doing it.

Re: The largest Git repo

#390

Post by Peaker »

eridius wrote: post #302
amag wrote: post #227

Earlier quoted context omitted.

It looks like git-mediate does one more important thing; it checks that the conflict is actually solved. In my experience it's very easy to miss something when manually resolving a conflict and often the choices the merge tools give you are not the ones you want.

Well, all it checks is that you modified the base case to look like one of the two other cases. That doesn't actually tell you if you resolved the conflict though, just that you copied one of the cases over the base case.

True, but if you follow a simple mechanical guideline: Apply the change 2 other versions (preferably the base one last) - then your conflict resolutions are going to be correct.

From experience with many developers using this method, conflict resolution errors went down to virtually zero, and conflict resolution time has improved by 5x-10x.

Post reply on HN