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

291–300 of 416 posts

Re: The largest Git repo

#291

Post by seanp2k2 »

dom0 wrote: post #205
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…

Also git rerere When maintaining multiple release lines and moving fixes between them: Don't use a bad branching model. Things like "merging upwards" (=committing fixes to the oldest branch requiring the fix, then merging the oldest branch into the next older branch etc.), which seems to be somewhat popular, just don't scale, don't work very well, and produce near-unreadable histories. They also incentivise developin…

Cherry picking hotfixes into maint branches is cool until you have stuff like diverging APIs or refactored modules between branches. I don't know of a better solution; it kind of requires understanding in detail what the fix does and how it does it, then knowing if that's directly applicable to every release which needs to be patched.

Re: The largest Git repo

#292

Post by fmihaila »

fmihaila wrote: post #88
criddell wrote: post #28

At one point, I believe Microsoft was using a modified Perforce server for source code. Is that completely gone now?

You are thinking of Google.

I meant that Google was the company who used Perforce in the past, and not Microsoft. Google isn't using it anymore either; they switched to their own thing named Piper.

https://www.wired.com/2015/09/google-2-billion-lines-codeand...

Re: The largest Git repo

#293

Post by srathi »

tokenizerrr wrote: post #245
MikeHolman wrote: post #221

Earlier quoted context omitted.

Generally, it's the responsibility of whoever made the changes to resolve conflicts (basically, git blame conflicting lines and the people who changed them get notified to resolve conflicts in that file). Distributing the work like this makes the merges more reasonable.

How does that work?

You first rebase against the master locally and push the merged feature branch after resolving all the conflicts yourself. Afterwards, you go to the master and merge it against the updated feature branch. The 2nd merge should not result in any conflicts.

Re: The largest Git repo

#294

Post by bpye »

kingbirdy wrote: post #12
hirsin wrote: post #10

Earlier quoted context omitted.

It's not included in Windows, which is why they have a signed drop of the driver for you to install. Even internally we have to install the driver. E- oops, missed that line. Cool, wonder if it will show up in more than Git

Yes, I was referring to the plan to include it in future Windows builds

Probably as an optional feature?

Re: The largest Git repo

#295

Post by farresito »

sbuttgereit wrote: post #280
farresito wrote: post #185

Earlier quoted context omitted.

They use mercurial (or were), which is as good as git. In fact, I bet a lot of people at Google are happy to use mercurial instead of git, given git's bad reputation with its command line interface.

You're thinking of Facebook if I'm not mistaken.

I had seen several sources that affirmed that Google used Mercurial, but I'm not sure to what extend, so I will retract it :-)

Re: The largest Git repo

#296

Post by cryptonector »

js2 wrote: post #145

Windows, because of the size of the team and the nature of the work, often has VERY large merges across branches (10,000’s of changes with 1,000’s of conflicts). At a former startup, our product was built on Chromium. As the build/release engineer, one of my daily responsibilities was merging Chromium's changes with ours. Just performing the merge and conflict resolution was anywhere from 5 minutes to an hour of my t…

Most changes don't touch hundreds/thousands of files. If you were to split the repo into many (as Windows used to be) then you'd still have the problem of huge projects having MANY conflicts, but worse: now you need to do your merge/rebase for each such repo.

In any case, rebasing is better than merging. (Rebasing is a series of merges, naturally, but still.)

Re: The largest Git repo

#297

Post by vtbassmatt »

fmihaila wrote: post #292
fmihaila wrote: post #88

Earlier quoted context omitted.

You are thinking of Google.

I meant that Google was the company who used Perforce in the past, and not Microsoft. Google isn't using it anymore either; they switched to their own thing named Piper. https://www.wired.com/2015/09/google-2-billion-lines-codeand...

SD was based on a very old Perforce as well.

Re: The largest Git repo

#298

Post by emmelaich »

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…

Are you saying that you use Git instead of Mercurial these days?

Not necessarily implied by you; just checking.

Re: The largest Git repo

#299

Post by emmelaich »

erikpukinskis wrote: post #126
vtbassmatt wrote: post #25

Earlier quoted context omitted.

Really good question. Actually, splitting Windows up was the first approach we investigated. Full details here: https://www.visualstudio.com/learn/gvfs-design-history/ Summary: - Complicates daily life for every engineer - Becomes hard to make cross-cutting changes - Complicates releasing the product - There's a still a core of "stuff" that's not easy to tease apart, so at least one of the smaller Windows repos would…

> - Becomes hard to make cross-cutting changes This does seem like a negative, doesn't it? But it's not. Making it hard to make cross-cutting changes is exactly the point of splitting up a repo. It forces you to slow down, and—knowing that you can only rarely make cross-cutting changes—you have a strong incentive to move module boundaries to where they should be. It puts pressure on you to really, actually separate c…

Making something difficult even more difficult is not helpful to anyone.

And what happens if the inherent difficult disappears or reduces? You're still left with the imposed external difficulty.

Re: The largest Git repo

#300

Post by caf »

taeric wrote: post #278
erikpukinskis wrote: post #266

Earlier quoted context omitted.

> At the end of the day, it's about getting work done, not making decisions that are the most "pure". This attitude will lead to a total breakdown of the development process over the long term. You are privileging Work Done At The End Of The Day over everything else. You need to consider work done at every relevant time scale. How much can you get done today? How much can you get done this month? How much can you get…

The linux codebase exists in stark contrast to your claim. Assuming your claim is that broken up repos is the better way.

The hierarchical merging workflow used by the Linux kernel does mean that there's more friction for wide-ranging, across-the-whole-tree changes than changes isolated to one subsystem.
Post reply on HN