3 ms·

Thought experiment: the entire github.com URL space is a single repository. Each organization/user has a top-level directory and projects/forks exist under them

Thought experiment: the entire github.com URL space is a single repository. Each organization/user has a top-level directory and projects/forks exist under them. Does that prevent/encourage code sharing? Why or why not?

viraptor 11y ago
Prevents. Instead of cloning just one of your repos and expecting it to work, I clone `indygreg2` and need to answer: - is there one build system for everything, or one per project? - are there dependencies between projects? - are they symlink-vendored? (which means that potentially I need more than one toolchain if projects A and B are in different languages) - are they completely separate? (do they always assume latest version of your projects, or do they have reasonable version qualifiers) - are any elements included cross-project, or can I just copy one directory and package it separately? Those and other similar questions just don't exist (in well maintained projects) that have separate repos. I know that I can clone one project and build it.
- indygreg2 11y ago
  Instead of cloning just one of your non-monolithic repositories and expecting it to "just work" I need to answer: - How does the build system integrate multiple, discrete repositories into a unified system? - What are the dependencies between the repositories? - How are the sub-repositories laid out on disk? Do the separate repositories use separate toolchains? - How do I decide when to update the reference to a sub-repository? Are they completely separate? Versioned as one logical entity? - Do separate repositories reference elements in each other? Can I copy files between repositories or should certain files live in certain repositories? These and other similar questions exist when you use multiple repositories. (I hope you see that multiple, discrete repositories aren't a panacea and there is a counterpoint to each of your points.)
  - viraptor 11y ago
    I don't agree with some of the counterpoints. Not because they couldn't exist in theory, but because we already worked out some common solutions for them and by cloning a separate repository, I expect that kind of problem to be one of: solved, documented in red big letters, or worthy of a bug report. 1. (build integration) All popular build systems have some dependency management answers. Even down to C's `autotools` and `pkg-config` which will at least tell you what you're missing. But more likely something like pip / gem / cargo which can just get it for you. Whether that's a released version, or another repo - none of my business. 2. (dependencies between repos) Same as 1. They're separate projects. I don't think these apply at all: 3. (sub-repositories) I don't see a difference between sub-repos and symlinking to a repo outside. This is a problem of single repo. 4. (sub-repositories update) Same as 3 - it's the same as one repository - avoid sub-repos unless you want to pretend you have one big repo with everything. 5. (moving elements) I think that's a straw man. Does anyone have a reasonable expectation that a file containing code can be moved between repositories without issues? While no repository layout is perfect and there are always pros and cons, I think those examples are really bad as counterpoints.

viraptor 11y ago

Prevents. Instead of cloning just one of your repos and expecting it to work, I clone `indygreg2` and need to answer: - is there one build system for everything, or one per project? - are there dependencies between projects? - are they symlink-vendored? (which means that potentially I need more than one toolchain if projects A and B are in different languages) - are they completely separate? (do they always assume latest version of your projects, or do they have reasonable version qualifiers) - are any elements included cross-project, or can I just copy one directory and package it separately? Those and other similar questions just don't exist (in well maintained projects) that have separate repos. I know that I can clone one project and build it.

indygreg2 11y ago
Instead of cloning just one of your non-monolithic repositories and expecting it to "just work" I need to answer: - How does the build system integrate multiple, discrete repositories into a unified system? - What are the dependencies between the repositories? - How are the sub-repositories laid out on disk? Do the separate repositories use separate toolchains? - How do I decide when to update the reference to a sub-repository? Are they completely separate? Versioned as one logical entity? - Do separate repositories reference elements in each other? Can I copy files between repositories or should certain files live in certain repositories? These and other similar questions exist when you use multiple repositories. (I hope you see that multiple, discrete repositories aren't a panacea and there is a counterpoint to each of your points.)
- viraptor 11y ago
  I don't agree with some of the counterpoints. Not because they couldn't exist in theory, but because we already worked out some common solutions for them and by cloning a separate repository, I expect that kind of problem to be one of: solved, documented in red big letters, or worthy of a bug report. 1. (build integration) All popular build systems have some dependency management answers. Even down to C's `autotools` and `pkg-config` which will at least tell you what you're missing. But more likely something like pip / gem / cargo which can just get it for you. Whether that's a released version, or another repo - none of my business. 2. (dependencies between repos) Same as 1. They're separate projects. I don't think these apply at all: 3. (sub-repositories) I don't see a difference between sub-repos and symlinking to a repo outside. This is a problem of single repo. 4. (sub-repositories update) Same as 3 - it's the same as one repository - avoid sub-repos unless you want to pretend you have one big repo with everything. 5. (moving elements) I think that's a straw man. Does anyone have a reasonable expectation that a file containing code can be moved between repositories without issues? While no repository layout is perfect and there are always pros and cons, I think those examples are really bad as counterpoints.