Boyd Stephen Smith Jr. schrieb: > In <[email protected]>, Thiago Macieira wrote: >> The problem happens when you try to push your nested sub-repositories to >> upstream servers. If one of them fails to push, you have to rebase or >> merge, which means the SHA-1 of the commit changes. And then you have to >> update the link in the parent repository. >> >> When you push the parent, then maybe that one fails as well to push. You >> have to merge and that may cause conflicts (maybe someone pushed an update >> to the repository you've just pushed and got to the parent before you >> did). You have to fix that manually as well. > > Oh. Now I get it. I'm just used to the git idea of a commit being a local > operation. So, using git/hg terminology, we would like an atomic cross- > repository *push*.
That this problem exits at all only shows that the intent that literally hundreds of people have push access to the same repository is flawed. But I know that I fight windmills :-( A compromise would be that push access to the KDE superproject is limited to only few people so that non-fast-forward pushes cannot happen so frequently. IOW, atomic cross-repository commits can be pushed only by those few people. This would mean that when (eg.) I have to make an atomic cross-repostory change, then: 1. I push the changes to my own public repositories; 2. ask one of those few (eg. "BD") to pull. 3. BD would merge with upstream (so that the pushes are fast-forwards); 4. BD would push the result; 5. BD would make the superproject commit and push that as well. -- Hannes _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
