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

341–350 of 416 posts

Re: The largest Git repo

#341

Post by rufius »

nojvek wrote: post #321
ry_ry wrote: post #189

Earlier quoted context omitted.

Such a relevant point, and I don't think they get enough props for it. I don't believe for one second this was a quick turnaround for them either. I've spoken to MS dev evangelists at work stuff over the past few years and they've continually said "it's going to get better", usually with a wry smile. It bloody did too. They're nowhere near perfect, and the different product branches remain as disjointed as ever, but…

Moving entire code base from source Depot (invented at Microsoft) git (not ms) was a huge undertaking. I know many ms devs who hated git. But this is seriously brave and well executed on their part.

Technically - Source Depot is a fork of Perforce. Not entirely invented at MSFT :).

Re: The largest Git repo

#342

Post by rufius »

ry_ry wrote: post #189
quotemstr wrote: post #157

I have tremendous respect for Microsoft pulling itself together over the past few years.

Such a relevant point, and I don't think they get enough props for it. I don't believe for one second this was a quick turnaround for them either. I've spoken to MS dev evangelists at work stuff over the past few years and they've continually said "it's going to get better", usually with a wry smile. It bloody did too. They're nowhere near perfect, and the different product branches remain as disjointed as ever, but…

To give you a little idea of scale - they've been at this for at least 4 years. It started while I still worked in Windows.

Re: The largest Git repo

#343

Post by Sacho »

graycat wrote: post #339
Sacho wrote: post #337

Earlier quoted context omitted.

The definitions of "git repo" and "ALM" are the top search result in google for both terms.

I can believe that. My point is, shouldn't articles define or at least give lines to definitions for terms? Apparently Google has discovered that their usual keyword/phrase search of Web pages should be set aside when a search is really for some jargon or and acronym and to do a special search, just for definitions, for such terms. So, if Google understands the crucial importance of unwinding jargon and acronyms, the…

This would create a lot of noise for the regular readers of his blog, who already know the definitions of these terms. The terms are not even obscure. This is also a blog, not a piece of technical documentation.

Re: The largest Git repo

#344

Post by cbhl »

Xorlev wrote: post #310
farresito wrote: post #295

Earlier quoted context omitted.

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

I'm sure there are a few teams that use Mercurial incidentally somewhere, but our primary megarepo is all on a VCS called Piper. Piper has a Perforce-y interface and there are experimental efforts to use Mercurial with Piper. Also mentioned in the article below, there's limited interop with a Git client. If you're curious what it all ends up looking like, read this article. It's a fairly good overview and reasonably…

IIRC, the git client is deprecated; the mercurial one is meant to replace it for the use cases where you would want a DVCS client interfacing with Piper in the first place.

Re: The largest Git repo

#345

Post by DominikD »

Sorry to see SourceDepot (slowly) decommissioned. I loved it and since it was a Perforce fork, what I've learned was directly applicable when I started using P4 in my subsequent job. Perhaps I'm old fashioned but I really see little appeal in DVCSes. I liked Hg but in the long run it's going to be completely run over by Git so I'd rather not invest in it. I'm rambling, sorry.

Re: The largest Git repo

#346

Post by sangnoir »

smitherfield wrote: post #322
sangnoir wrote: post #187

Earlier quoted context omitted.

Linus ought to be proud - it wasn't too long ago when Microsoft was calling his other work "a cancer", and now Windows depends on Git.Younger me would not believe this. Linus definitely is a rare genius on design and execution - he made his mark not only on Kernels/OSes, but on version control systems as well. I salute you, Linus!

If I recall correctly, wasn't the "cancer" remark in reference to the GPL?

Your recollection is inaccurate.

> Microsoft CEO and incontinent over-stater of facts Steve Ballmer said that "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches," during a commercial spot masquerading as a interview with the Chicago Sun-Times on June 1, 2001.[0]

https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_...

Re: The largest Git repo

#347

Post by dom0 »

lmitchell wrote: post #319
dom0 wrote: post #205

Earlier quoted context omitted.

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…

I don't understand the hate for merging up. I've worked with the 'cherry-pick into release branches' model, and also with an automated merge-upwards model, and I found the automerge to be WAY easier to deal with. If you make sure your automerge is integrated into your build system, so a failing automerge is a red build that sends emails to the responsible engineers, I found that doing it this way removed a ton of the…

As the branches diverge, merges take more and more time to do (up to a couple hours, at which point we abandoned the model)... they won't be done automatically. Since merges are basically context-free it's hard to determine the "logic" of changed lines. Since merges always contain a bunch of changes, all have to be resolved before they can be tested, and tracing failures back to specific conflict resolutions takes extra time. Reviewing a merge is seriously difficult. Mismerges are also far more likely to go unnoticed in a large merge compared to a smaller cherry pick. With cherry picking you are only considering one change, and you know which one. You only have to resolve that one change, and can then test, if you feel that's necessary, or move on to the next change.

Also; https://news.ycombinator.com/item?id=14413681

I also observed that getting rid of merging upwards moved the focus of development back to the actual development version (=master), where it belongs.

Re: The largest Git repo

#348

Post by dom0 »

seanp2k2 wrote: post #291
dom0 wrote: post #205

Earlier quoted context omitted.

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.

Yes, although this applies to all forms of porting changesets or patches between branches or releases.

Re: The largest Git repo

#349

Post by quotemstr »

cbhl wrote: post #344
Xorlev wrote: post #310

Earlier quoted context omitted.

I'm sure there are a few teams that use Mercurial incidentally somewhere, but our primary megarepo is all on a VCS called Piper. Piper has a Perforce-y interface and there are experimental efforts to use Mercurial with Piper. Also mentioned in the article below, there's limited interop with a Git client. If you're curious what it all ends up looking like, read this article. It's a fairly good overview and reasonably…

IIRC, the git client is deprecated; the mercurial one is meant to replace it for the use cases where you would want a DVCS client interfacing with Piper in the first place.

It's not deprecated. I use git-multi every day, much to the chagrin of my reviewers. Google thinks that long DIFFBASE chains are weird and exotic, and Google doesn't like weird and exotic as a rule.

Re: The largest Git repo

#350

Post by a_imho »

vtbassmatt wrote: post #207
YeGoblynQueenne wrote: post #191

So, if windows engineers are using git now, who is using TFVC? That's Team Foundation Version Control- the original TFS version control engine.

Lots and lots of external customers, and a handful of internal folks. FWIW Windows was never on TFVC (at least not the main development group).

What is the opposite of dogfooding?
Post reply on HN