1271013 - Allow to commit to git repo for mozilla-central

Status: RESOLVED WONTFIX

(Developer Services :: Git, enhancement)

Description

[Ben Bucksch (:BenB)]

This is a followup to bug 743626, for the second part: Ability to contribute with only git

The client should not need any hg or other special client software other than git. The server needs to behave exactly as any other git repository when pushing to it.


Original description:

I contribute to a number of projects, and have many of my own. Many Open-Source projects are using SVN, others (maybe even most by now) have advanced to git. hg is the only project I contribute to that uses hg.
Different VCS, while generally modeled around very similar concepts, are very different in subtle way, which make the daily use very different. I find myself struggling *for hours* each time I want to commit something to mozilla-central, and it doesn't seem to get better for me. I am just fed up with having to deal with 3-4 similar, yet different tools for the same thing.

hg and git are similar enough to make an automated sync possible:
* A public mozilla-central git repository that contains all changesets and history of hg mozilla-central. Ditto the other important branches like mozilla-inbound, releases/ and comm-central. (Solved in bug 743626)
* A public mozilla-inbound git repository that, when pushed to, invokes a hook to commit the same changeset to hg mozilla-inbound, using the same committer, so that I can contribute using git. (Still open, this bug here)
This should be possible without much trouble.

The advantage is:
1) Giving much easier access to Mozilla for new contributors (who probably know git, but not hg)
2) Allowing a smooth transition to git, or co-existance, allowing everybody to use the tool and workflow they prefer, forcing neither hg nor git on anybody.
3) Allowing better re-integration of those Mozilla lab projects that are already using git, e.g. Jetpack and others.

Comment 1

[Gregory Szorc [:gps]]

The proposal of standing up a Git repo that has its commits automagically converted to Mercurial at or shortly after push has been discussed at length previously. That proposal has been rejected.

One of the main objections is technical. Once you have a pushable Git server, you have 2 sources of truth. That creates races and syncing problems. I've worked on various syncing products over the span of my career and the one thing I've learned from syncing is that it is a fundamentally hard problem and should be avoided wherever possible. While we probably could solve the problem, it requires a lot of effort and this is not judged to be high priority or effective use of time for people who would work on it. There are also server-side technical reasons, such as probably needing to stand up Git and Mercurial on the same server to get the locking right (you need locking when you have distributed sources of truth) and performance acceptable. This has complications because Git and Mercurial have different scaling models (Git servers like to eat CPU cores). I'm not saying it can't be done. It's just complicated.

Another main reason we won't do this is because git-cinnabar should be "good enough." I say that because in the future world, you won't be pushing to mozilla-central or mozilla-inbound: the autoland service will do the landing. This means the proper things to request to lower the barrier to contributing with Git are a) a Git repo produced from git-cinnabar that people can easily `git clone` (possibly without git-cinnabar installed) b) a mechanism for MozReview/Autoland to consume Git commits (currently you submit to a Mercurial server via git-cinnabar). This is possibly the ability to consume GitHub Pull Requests.

In recap, standing up a pushable Git repo that effectively establishes a second master of Firefox history won't happen. Lowering the barrier to allow Git users to incorporate things into the canonical Mercurial repo can happen. Although you'll need to make a case that it is still too difficult: I haven't heard enough complaints about the current git-cinnabar solution being too difficult. I know its first-time setup isn't great, but people seem to get by. You need to convince us of the priority of taking additional action or nothing is likely going to happen. By "us" you can start with mcote for MozReview/Autoland and hwine for a Git repo produced from git-cinnabar (like gecko-dev).

Comment 2

[Mike Hommey [:glandium]]

In case you don't know about git-cinnabar, which having filed this bug suggests:
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial

(and you must know that you can use git-svn to deal with svn repositories while using git locally)

(In reply to Gregory Szorc [:gps] from comment #1)
> hwine for a Git repo produced from git-cinnabar (like gecko-dev).

We should start by producing new commits on gecko-dev with git-cinnabar.