21 ms·

April fool aside, what I really want is a Debian git monorepo of submodules, where each submodule points to the upstream git repository.

daghamm 3y ago
What do you think of the openbsd model? It has a mono repo for the os and a ports repo for everything else (I think)
- ninjin 3y ago
  Yes and no. OpenBSD uses four primary repositories: ports, src, www, and xenocara. CVS change announcements are merged for all but ports and go out on two mailing lists: source-changes@ and ports-changes@. Patches are discussed on tech@ and ports@ (sometimes also on bugs@). Also, some key software such as OpenSSH, OpenSMTPD, etc. is developed out-of-tree and lifted into the main train when appropriate. I am not a developer, but I do follow development somewhat closely.
XorNot 3y ago
You should check out dgit[1] which pretty much does exactly what you're looking for. It's an excellent way (with a little bit of pbuilder scripting) to patch Debian packages in place with sensible version numbering. [1] https://wiki.debian.org/DgitFAQ https://wiki.debian.org/DgitFAQ
tazjin 3y ago
Why use submodules when you can properly vendor the upstream git, and export/import commits without breaking hashes on either side? https://github.com/josh-project/josh https://github.com/josh-project/josh We've been using josh at TVL for years and it's just amazing.
- jcelerier 3y ago
  How does that work with upstreams that often needs patches?
  - tazjin 3y ago
    It depends on exactly what workflow you're trying to accomplish!) The parent comment seemed to be about a workflow where the repos are in sync. If you're carrying patches around and you don't want to export them, you are probably going to merging them. In either scenario if you have some patches you want to export and some you don't want to export, you'll either have to carry two trees, or do cherry-picking or something similar.
rkeene2 3y ago
What do you do about upstream projects that don't use Git ?
- kijin 3y ago
  Most non-git projects have git mirrors these days, even if they're not official. If upstream only releases tarballs, you can still untar them and create a commit for each version so you can easily compare them and merge any additional patches you need.
sunshowers 3y ago
Please never use submodules for anything, they cause a litany of problems now and down the road (have you ever tried deleting or renaming one?) The best thing to do is to pretend they don't exist.
eichin 3y ago
subtree might be better for exactly that? I have a project with about 100 repos, developing with them individually is so much saner, but every so often you want the one actual benefit of a monorepo: fast really-global search. So keeping a subtree-of-everything (using the bitbucket api to get the list of repos) and then just doing git-grep there when I want to see any use of something. (Somewhere there's an apt hook for "grab sources for everything that apt installs"; having that extract the source and git commit it, or just get the upstream repo from the metadata and `git subtree add` (or pull) wouldn't take much...)

daghamm 3y ago

What do you think of the openbsd model? It has a mono repo for the os and a ports repo for everything else (I think)

ninjin 3y ago
Yes and no. OpenBSD uses four primary repositories: ports, src, www, and xenocara. CVS change announcements are merged for all but ports and go out on two mailing lists: source-changes@ and ports-changes@. Patches are discussed on tech@ and ports@ (sometimes also on bugs@). Also, some key software such as OpenSSH, OpenSMTPD, etc. is developed out-of-tree and lifted into the main train when appropriate. I am not a developer, but I do follow development somewhat closely.

XorNot 3y ago

You should check out dgit[1] which pretty much does exactly what you're looking for. It's an excellent way (with a little bit of pbuilder scripting) to patch Debian packages in place with sensible version numbering. [1] https://wiki.debian.org/DgitFAQ https://wiki.debian.org/DgitFAQ

tazjin 3y ago

Why use submodules when you can properly vendor the upstream git, and export/import commits without breaking hashes on either side? https://github.com/josh-project/josh https://github.com/josh-project/josh We've been using josh at TVL for years and it's just amazing.

jcelerier 3y ago
How does that work with upstreams that often needs patches?
- tazjin 3y ago
  It depends on exactly what workflow you're trying to accomplish!) The parent comment seemed to be about a workflow where the repos are in sync. If you're carrying patches around and you don't want to export them, you are probably going to merging them. In either scenario if you have some patches you want to export and some you don't want to export, you'll either have to carry two trees, or do cherry-picking or something similar.

rkeene2 3y ago

What do you do about upstream projects that don't use Git ?

kijin 3y ago
Most non-git projects have git mirrors these days, even if they're not official. If upstream only releases tarballs, you can still untar them and create a commit for each version so you can easily compare them and merge any additional patches you need.

sunshowers 3y ago

Please never use submodules for anything, they cause a litany of problems now and down the road (have you ever tried deleting or renaming one?) The best thing to do is to pretend they don't exist.

eichin 3y ago

subtree might be better for exactly that? I have a project with about 100 repos, developing with them individually is so much saner, but every so often you want the one actual benefit of a monorepo: fast really-global search. So keeping a subtree-of-everything (using the bitbucket api to get the list of repos) and then just doing git-grep there when I want to see any use of something. (Somewhere there's an apt hook for "grab sources for everything that apt installs"; having that extract the source and git commit it, or just get the upstream repo from the metadata and `git subtree add` (or pull) wouldn't take much...)