4 ms·

Interesting tidbit: > The developers making Microsoft Windows use Git

by slobotron 8y ago

xkcdefgh 8y ago
Yeah, i believe it was a huge effort some time ago to migrate windows to git
- LyalinDotCom 8y ago
  Yep we use Git to build windows! here is the story that was told about our efforts. https://arstechnica.com/gadgets/2018/03/building-windows-4-million-commits-10-million-work-items/ https://arstechnica.com/gadgets/2018/03/building-windows-4-m...
  - LyalinDotCom 8y ago
    oh and also we did an interview with the DevOps lead for both source control and build system around Windows, so check that out too if you want: https://www.youtube.com/watch?v=nsXiKLLaH4M https://www.youtube.com/watch?v=nsXiKLLaH4M
01100011 8y ago
Kinda surprising. I know everyone seems to love git these days, but I find it's really better suited towards distributed and/or smaller projects. After feeling the pain of a megarepo system at work, I'm pushing to switch to a monorepo(well, like 4 repos instead of 200). git sort of sucks for monorepos. Also, even after learning a fair amount of git, I still find I spend a noticeable amount of time dealing with it. I don't remember spending a lot of time on any of the VCS systems I've used in the past. They just stayed out of my way and let do my thing.
- rtcoolaid 8y ago
  You are actually right and down voters have no clue (and this is what I hate about HN, if you don't comment then don't downvoye) To answer your question though - Microsoft has a lot of git extensions that they are slowly submitting upstream. Hence git is usable for their megarepo. Look up GVFS on GitHub, very cool work. Same for Twitter (they are not submitting upstream though as far as I know) Similar for fb/mercurial
- adrianN 8y ago
  I do a lot of things that aren't really possible in older VCS with git, which is why I spent more time with it.
  - gmueckl 8y ago
    I don't do new things in git, but since we transitioned, I spend about 3 to 4 times longer wrestling the VCS than with anything that I have used previously. This is merely for routine stuff, because it takes more steps
    - adrianN 8y ago
      The additional steps enable workflows that weren't possible before, so it's a tradeoff.
      - gmueckl 8y ago
        This argument is just wrong. I have fewer steps with less mental load on other VCS implementations, yet I can get better workflows at the same time with zero loss of functionality. Prime example: the git staging area/cache/index needs to die. Git would be half as difficult to use with fewer code shredding surprises. This abomination is a prime example of badly exposed internal structure. Everything feature that is crammed into this whatever-the-hell-that-is could be replaced by a vastly superior solution which does not require anything like it.
        nemetroid 8y ago
        The staging area is not necessary for your particular workflows. I found Mercurial horrible to work with precisely due to the lack of a staging step.
        erik_seaberg 8y ago
        Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.
- pdpi 8y ago
  > git sort of sucks for monorepos. Microsoft works around several of the issues there by using GVFS. Also, at Microsoft scale, everything "sort of sucks", there's just no silver bullets. You take one of the least bad options and put all the effort you can towards making it work as well as you can.
  - a-dub 8y ago
    No. Everything only "sort of sucks" at "Microsoft scale" if you're willing to blame it on "scale." At "Microsoft scale," you have the resources to purpose build anything you need from scratch for any scale you're working at... therefore if anything "sort of sucks" it's because: a) It's not worth the money/resources. (The "let it suck" approach) or b) Nobody cares (The "acceptance that we suck, at 'scale'" approach)
    - a-dub 8y ago
      ... and I'm going to belabor this, because I think it's important. There's a fair bit of excitement around the new, exciting, open source friendly Microsoft with built-in Linux kernel emulation, an embrace of git and a huge release of open source tools... Honestly though, I'm not buying it, the issue I've had with Microsoft over the years doesn't just stem from the shitty software or aggressive business practices... it's the deep rooted culture of mediocrity it promotes. People who belong to that church believe it's ok to build shitty software because doing it right is too hard. Why root-cause an issue when you can just script reboots? It's too hard anyway, we're at "Microsoft scale." The rise of the internet and the companies that grew around it showed us that if you have a culture of giving a shit, you can build really complex things "at scale" that aren't complete shit. I worry that the new Microsoft will be a different kind of trojan horse for the OSS world. It won't be "embrace, extend, extinguish" it will be more like a social media psyops campaign that beats it into everyone's heads that now we're at "Microsoft scale" it's ok for everything to "kinda suck", and if we're not careful... everything will.
- MaxBarraclough 8y ago
  > I find it's really better suited towards distributed and/or smaller projects But it was specifically designed for the Linux kernel.
  - rootlocus 8y ago
    Which is highly distributed with multiple contributors, maintainers, etc. The "monolithic" aspect is just one glorified repo: Linus's

Interesting tidbit: > The developers making Microsoft Windows use Git

xkcdefgh 8y ago

Yeah, i believe it was a huge effort some time ago to migrate windows to git

LyalinDotCom 8y ago
Yep we use Git to build windows! here is the story that was told about our efforts. https://arstechnica.com/gadgets/2018/03/building-windows-4-million-commits-10-million-work-items/ https://arstechnica.com/gadgets/2018/03/building-windows-4-m...
- LyalinDotCom 8y ago
  oh and also we did an interview with the DevOps lead for both source control and build system around Windows, so check that out too if you want: https://www.youtube.com/watch?v=nsXiKLLaH4M https://www.youtube.com/watch?v=nsXiKLLaH4M

01100011 8y ago

Kinda surprising. I know everyone seems to love git these days, but I find it's really better suited towards distributed and/or smaller projects. After feeling the pain of a megarepo system at work, I'm pushing to switch to a monorepo(well, like 4 repos instead of 200). git sort of sucks for monorepos. Also, even after learning a fair amount of git, I still find I spend a noticeable amount of time dealing with it. I don't remember spending a lot of time on any of the VCS systems I've used in the past. They just stayed out of my way and let do my thing.

rtcoolaid 8y ago
You are actually right and down voters have no clue (and this is what I hate about HN, if you don't comment then don't downvoye) To answer your question though - Microsoft has a lot of git extensions that they are slowly submitting upstream. Hence git is usable for their megarepo. Look up GVFS on GitHub, very cool work. Same for Twitter (they are not submitting upstream though as far as I know) Similar for fb/mercurial
adrianN 8y ago
I do a lot of things that aren't really possible in older VCS with git, which is why I spent more time with it.
- gmueckl 8y ago
  I don't do new things in git, but since we transitioned, I spend about 3 to 4 times longer wrestling the VCS than with anything that I have used previously. This is merely for routine stuff, because it takes more steps
  - adrianN 8y ago
    The additional steps enable workflows that weren't possible before, so it's a tradeoff.
    - gmueckl 8y ago
      This argument is just wrong. I have fewer steps with less mental load on other VCS implementations, yet I can get better workflows at the same time with zero loss of functionality. Prime example: the git staging area/cache/index needs to die. Git would be half as difficult to use with fewer code shredding surprises. This abomination is a prime example of badly exposed internal structure. Everything feature that is crammed into this whatever-the-hell-that-is could be replaced by a vastly superior solution which does not require anything like it.
      - nemetroid 8y ago
        The staging area is not necessary for your particular workflows. I found Mercurial horrible to work with precisely due to the lack of a staging step.
        erik_seaberg 8y ago
        Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.
pdpi 8y ago
> git sort of sucks for monorepos. Microsoft works around several of the issues there by using GVFS. Also, at Microsoft scale, everything "sort of sucks", there's just no silver bullets. You take one of the least bad options and put all the effort you can towards making it work as well as you can.
- a-dub 8y ago
  No. Everything only "sort of sucks" at "Microsoft scale" if you're willing to blame it on "scale." At "Microsoft scale," you have the resources to purpose build anything you need from scratch for any scale you're working at... therefore if anything "sort of sucks" it's because: a) It's not worth the money/resources. (The "let it suck" approach) or b) Nobody cares (The "acceptance that we suck, at 'scale'" approach)
  - a-dub 8y ago
    ... and I'm going to belabor this, because I think it's important. There's a fair bit of excitement around the new, exciting, open source friendly Microsoft with built-in Linux kernel emulation, an embrace of git and a huge release of open source tools... Honestly though, I'm not buying it, the issue I've had with Microsoft over the years doesn't just stem from the shitty software or aggressive business practices... it's the deep rooted culture of mediocrity it promotes. People who belong to that church believe it's ok to build shitty software because doing it right is too hard. Why root-cause an issue when you can just script reboots? It's too hard anyway, we're at "Microsoft scale." The rise of the internet and the companies that grew around it showed us that if you have a culture of giving a shit, you can build really complex things "at scale" that aren't complete shit. I worry that the new Microsoft will be a different kind of trojan horse for the OSS world. It won't be "embrace, extend, extinguish" it will be more like a social media psyops campaign that beats it into everyone's heads that now we're at "Microsoft scale" it's ok for everything to "kinda suck", and if we're not careful... everything will.
MaxBarraclough 8y ago
> I find it's really better suited towards distributed and/or smaller projects But it was specifically designed for the Linux kernel.
- rootlocus 8y ago
  Which is highly distributed with multiple contributors, maintainers, etc. The "monolithic" aspect is just one glorified repo: Linus's