9 ms·

On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some p

by amag 9y ago

On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file! "Because then you can just set up your project as using version X of file A and version Y of file B" It's good we now have (at least) Google, Facebook and Microsoft as examples of companies using monorepos. Those are names that carry some weight when thrown into a conversation.

humanrebar 9y ago
Google, Facebook, and Microsoft also make significant investments in tooling to get their monorepos to work. Picking a good package manager (or artifact repository) and making it a part company culture could be less work, depending on the context.
chimeracoder 9y ago
> On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file! "Because then you can just set up your project as using version X of file A and version Y of file B" This basically sounds like CVS.
- StillBored 9y ago
  If that is how you were using CVS, its no surprise that it gets so much hate. OTOH, I think the common CVS workflow actually matches the modern "we don't do stable branches" workflow a lot better than git does. Basically, if you had upstream CVS branches for more than released versions of software in maintenance mode you were doing it wrong. I also tend to yearn for the days when I didn't spend 20% of my time rebasing and merging patches together, or rewritting dozens of patches worth of git history in order to move a couple minor commit hunks between patches for some reviewer. Or just juggling 20 different -next style remote repos. Git is one of those tools that let you endlessly play with your tools rather than getting the job done.
  - hyperpape 9y ago
    What workflow do you use with git that has you doing so much juggling?
    - gmueckl 9y ago
      Pick one. I have yet to encounter a workflow that did not introduce tons of extra fiddling and stupid busywork.
      - tome 9y ago
        Exactly the same workflow you were using with CVS?
      - lmm 9y ago
        http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html is the style I favour. It certainly involves steps but every distinction it forces you to draw feels meaningful (at least to me), with the possible exception of the commit/push distinction which is a performance optimisation (I certainly wouldn't want to have to wait for a push on every commit).
  - chousuke 9y ago
    > Git is one of those tools that let you endlessly play with your tools rather than getting the job done I vehemently disagree with this sentiment. In fact, I find the opposite to be true. Git is the first VCS I used that is useful during coding instead of after it, when it's time to publish the final product, ie. a changeset. I can commit, merge, branch, rewrite and share changes freely and effortlessly whenever I need to without committing a bunch of crap to the shared repository that is of no interest to anyone. After I'm finished getting shit done, I can then spend some time reviewing and thinking about the logical progression of changes so that the commit log will be readable to other people and older me. This is often just as valuable as writing the code itself.
deleted 9y ago
[deleted]
tdumitrescu 9y ago
That sweet abuse of version control reminds me of the fabled JDSL from http://thedailywtf.com/articles/the-inner-json-effect http://thedailywtf.com/articles/the-inner-json-effect
- mathgladiator 9y ago
  That can't be real... is it? No. No way.
  - sandos 9y ago
    It has to be made up. I am with you, that can no be real. There are trolls for everything.
    - mathgladiator 9y ago
      It is so well crafted that it must be rooted in truth... I just... no. No way. This is too much madness...
      - icc97 9y ago
        Seems interesting that he would put in comment examples that would delete the entire database. Perhaps the guy telling the story is what happened when little Bobby Tables grew up.
  - mercer 9y ago
    It strikes me as /r/nosleep but for IT.
  - jonex 9y ago
    TDWTF started modifying their stories significantly to avoid people getting in trouble due to telling the stories. Sadly this was used as an opportunity to significantly embellish the stories to the extent that often the major weird thing told about is all made up.
adrianN 9y ago
Those people probably were used to a VCS like Clearcase where this is standard practice. If your process grew around something like that and depends on it it might seem reasonable to try and emulate it in the new system, to reduce the amount of stuff you need to change and learn.
uiri 9y ago
Microsoft doesn't really use a monorepo (although they may have done so in the past). Everything is moving to git, and while they've invested significant effort into getting git to handle larger repos, you don't have everything living in one repo quite the same way that Google does it. My understanding of Google's monorepo is that search, mail, maps, etc. all live inside one repo.
- amag 9y ago
  Uh, they moved all of Windows into a single git-repo. It used to sprawl over 40+ Source Depot repos but now it's one gigantic monorepo [1]. [1] https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g...
  - uiri 9y ago
    Right, but Office, SQL Server and Azure don't live beside it in the same repo. Windows is one project. The FreeBSD base system lives in one repository but I wouldn't call it a monorepo.
lloeki 9y ago
For a close enough real life example, and very often just one file (PKGBUILD), ArchLinux uses one (orphaned) branch per package: https://git.archlinux.org/svntogit/packages.git/refs https://git.archlinux.org/svntogit/packages.git/refs https://git.archlinux.org/svntogit/community.git/refs https://git.archlinux.org/svntogit/community.git/refs Orphaned branches allows you to have multiple independent trees in the same git repo, si it's basically a way to stuff many "repos" (as in history) in a single one (as in object storage).
- markild 9y ago
  That seems very weird. Do you happen to know the reasoning behind it?
  - scrollaway 9y ago
    Arch maintainer here. Arch Linux doesn't use git, it uses svn still. Each arch package-repository (core, extra, community...) is a single SVN repository. Packages are split in subdirectories in that repository and checked out individually. Every maintainer deals with a few dozen packages individually, not the whole. There are seldom any commits that span multiple repositories. What you were linked is the "svn to git" mirror which has to somehow translate that aspect of the setup to git. Incidentally, the way Arch svn is currently set up works really well for arch devs and it is very hard to find a good replacement to it using git. Having a monorepo split up in lots of microrepos is straight up not possible in git.
    - lloeki 9y ago
      > Having a monorepo split up in lots of microrepos is straight up not possible in git. Not saying you should, but if your goal is to have a single repo (VCS) per repo (Arch) within which all packages are stored, and replicate the {core/{foo,bar,baz},extra/{qux,tor,meh}} tree, there could be many ways to do it depending on the exact needs, by leveraging GIT_DIR, GIT_WORK_TREE, GIT_OBJECT_DIRECTORY, GIT_ALTERNATE_OBJECT_DIRECTORIES, clone --single-branch and checkout --orphan. Single monorepo with orphan branches, single clone, multiple work trees: # create monorepo mkdir core cd core git init --bare .git export GIT_DIR=$(PWD)/.git # add package in its own branch isolated export GIT_WORK_TREE=$(PWD)/bash mkdir bash cd bash git checkout --orphan bash git add PKGBUILD git commit # switch package export GIT_WORK_TREE=$(PWD)/readline mkdir readline cd readline git checkout --orphan readline git add PKGBUILD git commit # back to bash export GIT_WORK_TREE=$(PWD)/bash cd bash git checkout bash But each time you switch you have to switch the branch too since HEAD is in core/.git, so to work around that you can share the object dir. Single monorepo with orphan branches, multiple clones but shared object dir, multiple work trees: mkdir core cd core export GIT_OBJECT_DIRECTORY=$(PWD)/.git_objects mkdir bash cd bash GIT_DIR=$(PWD)/.git git init # otherwise .git will be created next to .git_objects git checkout --orphan bash touch PKGBUILD git add PKGBUILD git commit -m "Add package: bash" cd .. mkdir readline cd readline GIT_DIR=$(PWD)/.git git init git checkout --orphan readline touch PKGBUILD git add PKGBUILD git commit -m "Add package: readline" # back to bash cd ../bash git branch # just to check it's "bash", not "readline" # clone existing package cd .. git clone some.where:core.git --single-branch --branch libarchive cd libarchive That's from the top of my head, and well it very much depends on what you want to achieve as a workflow.

by amag 9y ago

humanrebar 9y ago

Google, Facebook, and Microsoft also make significant investments in tooling to get their monorepos to work. Picking a good package manager (or artifact repository) and making it a part company culture could be less work, depending on the context.

chimeracoder 9y ago

> On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file! "Because then you can just set up your project as using version X of file A and version Y of file B" This basically sounds like CVS.

StillBored 9y ago
If that is how you were using CVS, its no surprise that it gets so much hate. OTOH, I think the common CVS workflow actually matches the modern "we don't do stable branches" workflow a lot better than git does. Basically, if you had upstream CVS branches for more than released versions of software in maintenance mode you were doing it wrong. I also tend to yearn for the days when I didn't spend 20% of my time rebasing and merging patches together, or rewritting dozens of patches worth of git history in order to move a couple minor commit hunks between patches for some reviewer. Or just juggling 20 different -next style remote repos. Git is one of those tools that let you endlessly play with your tools rather than getting the job done.
- hyperpape 9y ago
  What workflow do you use with git that has you doing so much juggling?
  - gmueckl 9y ago
    Pick one. I have yet to encounter a workflow that did not introduce tons of extra fiddling and stupid busywork.
    - tome 9y ago
      Exactly the same workflow you were using with CVS?
    - lmm 9y ago
      http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html is the style I favour. It certainly involves steps but every distinction it forces you to draw feels meaningful (at least to me), with the possible exception of the commit/push distinction which is a performance optimisation (I certainly wouldn't want to have to wait for a push on every commit).
- chousuke 9y ago
  > Git is one of those tools that let you endlessly play with your tools rather than getting the job done I vehemently disagree with this sentiment. In fact, I find the opposite to be true. Git is the first VCS I used that is useful during coding instead of after it, when it's time to publish the final product, ie. a changeset. I can commit, merge, branch, rewrite and share changes freely and effortlessly whenever I need to without committing a bunch of crap to the shared repository that is of no interest to anyone. After I'm finished getting shit done, I can then spend some time reviewing and thinking about the logical progression of changes so that the commit log will be readable to other people and older me. This is often just as valuable as writing the code itself.

deleted 9y ago

[deleted]

tdumitrescu 9y ago

That sweet abuse of version control reminds me of the fabled JDSL from http://thedailywtf.com/articles/the-inner-json-effect http://thedailywtf.com/articles/the-inner-json-effect

mathgladiator 9y ago
That can't be real... is it? No. No way.
- sandos 9y ago
  It has to be made up. I am with you, that can no be real. There are trolls for everything.
  - mathgladiator 9y ago
    It is so well crafted that it must be rooted in truth... I just... no. No way. This is too much madness...
    - icc97 9y ago
      Seems interesting that he would put in comment examples that would delete the entire database. Perhaps the guy telling the story is what happened when little Bobby Tables grew up.
- mercer 9y ago
  It strikes me as /r/nosleep but for IT.
- jonex 9y ago
  TDWTF started modifying their stories significantly to avoid people getting in trouble due to telling the stories. Sadly this was used as an opportunity to significantly embellish the stories to the extent that often the major weird thing told about is all made up.

adrianN 9y ago

Those people probably were used to a VCS like Clearcase where this is standard practice. If your process grew around something like that and depends on it it might seem reasonable to try and emulate it in the new system, to reduce the amount of stuff you need to change and learn.

uiri 9y ago

Microsoft doesn't really use a monorepo (although they may have done so in the past). Everything is moving to git, and while they've invested significant effort into getting git to handle larger repos, you don't have everything living in one repo quite the same way that Google does it. My understanding of Google's monorepo is that search, mail, maps, etc. all live inside one repo.

amag 9y ago
Uh, they moved all of Windows into a single git-repo. It used to sprawl over 40+ Source Depot repos but now it's one gigantic monorepo [1]. [1] https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g...
- uiri 9y ago
  Right, but Office, SQL Server and Azure don't live beside it in the same repo. Windows is one project. The FreeBSD base system lives in one repository but I wouldn't call it a monorepo.

lloeki 9y ago

For a close enough real life example, and very often just one file (PKGBUILD), ArchLinux uses one (orphaned) branch per package: https://git.archlinux.org/svntogit/packages.git/refs https://git.archlinux.org/svntogit/packages.git/refs https://git.archlinux.org/svntogit/community.git/refs https://git.archlinux.org/svntogit/community.git/refs Orphaned branches allows you to have multiple independent trees in the same git repo, si it's basically a way to stuff many "repos" (as in history) in a single one (as in object storage).

markild 9y ago
That seems very weird. Do you happen to know the reasoning behind it?
- scrollaway 9y ago
  Arch maintainer here. Arch Linux doesn't use git, it uses svn still. Each arch package-repository (core, extra, community...) is a single SVN repository. Packages are split in subdirectories in that repository and checked out individually. Every maintainer deals with a few dozen packages individually, not the whole. There are seldom any commits that span multiple repositories. What you were linked is the "svn to git" mirror which has to somehow translate that aspect of the setup to git. Incidentally, the way Arch svn is currently set up works really well for arch devs and it is very hard to find a good replacement to it using git. Having a monorepo split up in lots of microrepos is straight up not possible in git.
  - lloeki 9y ago
    > Having a monorepo split up in lots of microrepos is straight up not possible in git. Not saying you should, but if your goal is to have a single repo (VCS) per repo (Arch) within which all packages are stored, and replicate the {core/{foo,bar,baz},extra/{qux,tor,meh}} tree, there could be many ways to do it depending on the exact needs, by leveraging GIT_DIR, GIT_WORK_TREE, GIT_OBJECT_DIRECTORY, GIT_ALTERNATE_OBJECT_DIRECTORIES, clone --single-branch and checkout --orphan. Single monorepo with orphan branches, single clone, multiple work trees: # create monorepo mkdir core cd core git init --bare .git export GIT_DIR=$(PWD)/.git # add package in its own branch isolated export GIT_WORK_TREE=$(PWD)/bash mkdir bash cd bash git checkout --orphan bash git add PKGBUILD git commit # switch package export GIT_WORK_TREE=$(PWD)/readline mkdir readline cd readline git checkout --orphan readline git add PKGBUILD git commit # back to bash export GIT_WORK_TREE=$(PWD)/bash cd bash git checkout bash But each time you switch you have to switch the branch too since HEAD is in core/.git, so to work around that you can share the object dir. Single monorepo with orphan branches, multiple clones but shared object dir, multiple work trees: mkdir core cd core export GIT_OBJECT_DIRECTORY=$(PWD)/.git_objects mkdir bash cd bash GIT_DIR=$(PWD)/.git git init # otherwise .git will be created next to .git_objects git checkout --orphan bash touch PKGBUILD git add PKGBUILD git commit -m "Add package: bash" cd .. mkdir readline cd readline GIT_DIR=$(PWD)/.git git init git checkout --orphan readline touch PKGBUILD git add PKGBUILD git commit -m "Add package: readline" # back to bash cd ../bash git branch # just to check it's "bash", not "readline" # clone existing package cd .. git clone some.where:core.git --single-branch --branch libarchive cd libarchive That's from the top of my head, and well it very much depends on what you want to achieve as a workflow.