- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Wed, 03 Jul 2013 10:28:21 +0100
- To: Peter Linss <peter.linss@hp.com>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Charles McCathie Nevile <chaals@yandex-team.ru>
Le 02/07/2013 19:51, Peter Linss a écrit : > On Jun 25, 2013, at 12:14 PM, Tab Atkins Jr. wrote: >> On Tue, Jun 25, 2013 at 11:20 AM, Peter Linss<peter.linss@hp.com> >> wrote: >>> I've been exploring what it would take to make the bridge >>> bi-directional, allowing pushing to either repository. There have >>> been some attempts which work for simple cases, but there are >>> gotchas dealing with branches... >> >> We shouldn't worry about branches - only the master branch should >> be canonical. Ideally, we should reject pushing non-master >> branches to the repo. > Unfortunately it's not so simple. I'm also not just talking about > long-term, named branches, but the local, unnamed branches that are > just part of the workflow of a dvcs. We can only enforce the end > state of what someone pushes, if we try to enforce intermediate > steps, it's way too easy for someone to get their local repo into a > state where they can never push again. There's nothing preventing > people from creating and merging branches locally. I don’t see what your concern is, Peter. We could reject pushing to non-default branches on dvcs.w3.org/hg/csswg (and non-master branches on GitHub, if they have that feature), that wouldn’t at all prevent people from having many branches in their local repositories. Now I’m not sure we *want* that, but if it helps with hg/git interop I’m all for it. -- Simon Sapin
Received on Wednesday, 3 July 2013 09:28:48 UTC