Hi! > Well dpkg already has multiple repos, and they are being kept in sync, > by having a main instance and then replicas! I think doing this > automatically without a merge-based workflow, for multiple pushers, > would either be racy, or not possible at all w/o making a mess of it.
Git fully supports accepting Merge Requests / Pull Requests from multiple places. You just apply the commit on the main place like you usually do and push and you are all good. > > Under no situation would a sync of the mirror overwrite the Merge > > Requests. If I for example file a Merge Request at > > https://salsa.debian.org/dpkg-team/dpkg from a source branch in my own > > fork, there is no way for you to overwrite that merge request branch. > > Your own fork should indeed be safe from overwrites, but that was not > my point :), AFAIUI GitLab based forges store MRs against that project > as refs under the refs/nerge-requests hierarchy, that's why you can > fetch them remotely by adding something like this in your local tree > under .git/config: > > [remote "some-name"] > url = git@gitlab-url:repo/repo.git > fetch = +refs/heads/*:refs/remotes/some-name/* > fetch = +refs/merge-requests/*/head:refs/remotes/some-name/mr/* > > Then when you fetch, you'll see the MRs as those branches for that > remote. A «git push --mirror» will forcibly add, update or delete > remote branches to match the local (on the git server) bare repo, and > my assumption has always been that this would remove those refs, but > perhaps GitLab protects them someway and does not let you remove them > even by force, or when mirroring. TBH have never bother to test that, > but I think that's a bit besides the point as I mentioned. You have a very elaborate explanation of something that nobody does, never has happened, and which is not even technically possible. What you are indirectly expressing here is just that you don't like Salsa/GitLab and don't want to learn or think how it works or what benefits it brings, but rather focus on coming up with reasons not to use it, even imaginary ones. ... > One of the concerns is that this spreads this information for the > project, so that others will have a harder time seeing where things > are happening, and stores that information in a place where it will > be harder to extract (once, not if) Salsa goes away. With git being Everything relevant about the code change is in the git commit message itself. I don't think allowing Merge Requests on Salsa would mean that you need to store the metadata about MRs forever. They are useful to facilitate making the change, such as tracking if the code passes CI and what is the state of the MR. Once it is merged or closed it is fine to forget about the MR. ... > primary hosting site, and there that makes perfect sense. Although > GitLab or GitHub review capabilities are not very ideal compared to > either mail based workflows or even Gerrit. Salsa is also very slow, > which is quite frustrating. GitLab and GitHub track things like CI and submission status, which is completely missing from email. And both on GitLab and GitHub you can actually also review by email if you don't want to be assisted by the UI. I do agree on the slowness, and have filed https://salsa.debian.org/salsa/support/-/issues/395 > But in any case, just to wrap up, this is not about not knowing how > these forges work, or their potential advantages, etc. I'm open to > reconsider this in general, and I've also been pondering for a while The fact that your first response to this bug report was to immediately close it paints a clear picture that you have a strong gut feeling is against the proposal, and your half-arguments reflect that you really want to come up with reasons to not support MRs. I just wish you would have replied simply that you don't like using Salsa MRs but left the bug report open for more people to potentially voice their opinion (assuming there is dpkg-team, perhaps there isn't).
