> On a different gear, would we want to keep m-c/m-i/projects etc. as separate > git repos, or could we make them branches in a merged repo?
Many hours of sleep have been lost fighting over the answer to this question -- the debate lasted for almost a year., with strong advocates on both sides. We've pretty solidly decided that it's better to have just one git repo. Without rehashing a yearlong discussion: One repo is more git-like. If releng wants to have a mirror of the main repo that contains only certain branches, that's fine. > Also, note that a historical weakness of our hg usage has been onboarding > education. I've been working on-and-off on a "git for mozilla hackers" blog post, and I hear that gps is too. That's not a magic wand, but it's something. On Tue, Jun 11, 2013 at 6:32 PM, Steve Fink <sf...@mozilla.com> wrote: > For me, the most appealing reason to switch to git is so that we can get > back to having a single revision control system, but I think the benefit of > that is probably outweighed by the churn. We'd need to rewrite a lot of > stuff simultaneously, more or less. > > As for supporting both, I have a hard time forming an opinion on it without > having a clue what the cost would be. Clearly, it would involve a lot of > effort to support git's idiosyncrasies and failure modes (even if git ends > up being better overall for our needs than hg.) What's the opportunity cost? > What would get stalled, postponed, or scrapped? And what status quo-ish > alternative are we talking about, given that we have to gradually support > git in more and more places due to existing usage and external dependencies? > > In short, it's hard to have an opinion about a decision when it's unclear > what the decision means. Is it that git becomes "tier 1" and anything you > cannot do with git that you can do with hg automatically becomes a blocker? > Or is it just a request "please prioritize things that will improve git > support a little higher than you have in the past"? You've laid out some > concrete milestones in your original email, but I don't know how those > milestones would be prioritized relative to the one or two other little > things that releng and IT are working on already. > > On a different gear, would we want to keep m-c/m-i/projects etc. as separate > git repos, or could we make them branches in a merged repo? Separate repos > feel like a mercurial-induced nuisance to me. (I'd prefer > aurora/beta/release to be in the same repo too, not that I truly understand > the repercussions.) > > Also, note that a historical weakness of our hg usage has been onboarding > education. Adding git as an alternative would improve this for people > already accustomed to git, but would make the situation worse for anyone who > isn't already comfortable with the more advanced usage of either git or > mercurial. (I assert that nontrivial git is harder to learn, and we're > already not doing a good job with nontrivial hg education.) It's somewhat > tangential, but it would be cool if somebody could wave a magic wand and > address education at the same time -- if only to prevent a bad situation > from becoming worse. > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
