XPost: linux.debian.bugs.dist
From:
[email protected]
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).
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)