On 2014-10-31 1:48 AM, Gregory Szorc wrote:
I'm trying to learn more about how the people who use Git for
Firefox/Gecko development manage interacting with repositories that have
their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing
this to ensure the replacement Try architecture will be usable by Git
users.
I'm looking for more information and trying to tease out the relative
popularity and pain points of the technical solutions for the following
tasks:
a) Landing code to inbound, fx-team, aurora, etc
I have the following git alias:
hgp = show -M -C --binary --full-index --format=\"From: %an
<%ae>%nSubject: %s%n%n%b\" -U8
And my workflow for landing code is like this:
$ cd /path/to/src # this is a git repo
$ git hg commit_id > /tmp/x
$ cd /path/to/inbound # this is an hg repo
$ hg pull -u
$ hg qim /tmp/x && hg qpush && hg qfi -a && hg push
As you can imagine, this *sucks*.
b) Pushing to Try
Same as above, except that I use a copy of m-c hg repo for most of my
try pushes. After I push to try, I qpop and qrm the patch. If I need
to repush to try, I'll make my changes on the git side and rinse and
repeat from above.
This also sucks.
c) Fetching new commits
Not sure what you mean here. git fetch works very well!
d) Collaborating/sharing commits with others, especially hg<->git sharing
I have occasionally published my changes on github. hg<->git sharing is
in my experience more of a dream, so these days if I need to share code
with an hg user, the practical choice is to send them a patch. (Or get
them to use git for collaboration.)
I found https://etherpad.mozilla.org/moz-git-tools and the like-named
GitHub repo with a suite of Mozilla-centric Git commands. These seem to
be largely based on top of low-level patch format conversion and make
little attempt (if any) to preserve commit SHA-1 mappings to enable
bi-directional conversion (i.e. they are unidirectional, lossy tools).
Many of them seem to have `hg` invocations buried under the covers.
I believe most of those tools were written by the amazing Justin Lebar,
and he asked me to maintain that repo when he left Mozilla. I have
admittedly not done much. The only tool that I use from that repo is
git-bz. I literally can't live without it. Prior to that, the process
of submitting something for review was also exporting a textual patch to
/tmp/x and attaching it to Bugzilla.
(As I understand things, with the new reviewboard system this workflow
would go back to the usual suckiness of dealing with hg, unfortunately...)
I'm interested in knowing how people feel about these "hidden hg" tools.
Is going through a hidden, local hg bridge seamless? Satisfactory?
Barely tolerable? A horrible pain point? (I noticed some of the hg
interactions in moz-git-tools aren't optimal. If these are important
tools, please ping me off list so I can help you improve them.)
I'd say barely tolerable. This has actually changed my workflow. For
example, I go to great lengths to avoid pushing anything to try. Also,
I have avoided fixing many small issues because the process overhead
makes it not worth my time, and the process for landing the change
(which typically takes at least a few minutes, assuming I don't make a
mistake along the way) is a great part of it.
Is moz-git-tools the de facto standard for Mozilla developers? Are there
other competing tools?
I have heard that other people also do things manually.
There is <https://github.com/nbp/git-hg-bridge>, written by nbp. It's a
git server side hook that accepts a push, and pushes it to the hg side.
I have tried that and it's *amazing*, it basically enables you to just
type in git push, and not be bothered by hg at all.
The implementation has a number of issues with holding global locks
which makes it unsuitable for usage by more than one person. It would
be *amazing* if Mozilla could sponsor a version of this solution. I
believe that is the ideal solution to this problem, and it can at least
serve as a benchmark to judge the quality of any alternative solution.
Does anyone use hg-git (it has gotten *much* faster in the past year
thanks to Facebook's investment)?
I recently tried to use it for the Nth time. It could be that I don't
know what I'm supposed to do exactly, but this time I tried something
along the lines of
<http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-in-git-and-push-to-hg/>.
It didn't work, unfortunately. The hg gimport process fails after a
day or so. Have you had any luck with getting it to work in the git ->
hg direction? (I know that it works well in the opposite direction.)
I'm particularly interested in knowing if any Git developers have been
able to eliminate local hg completely. i.e. you are fetching and pushing
from/to Git repos exclusively. If so, what are you using? What
limitations do you have?
I have considered writing a git server as an extension to nbp's tool
that solves the issue for multiple users, but have chosen to not do so
because I didn't want to end up maintaining this server for years. I
would be more than happy to help anyone who's willing to step up. :-)
Overall, how happy are you with your Git fetch/push workflows?
Not happy in the slightest. :-)
> Short of
switching the canonical repositories to Git, what do you need to be more
productive?
I actually don't advocate switching our canonical repos to Git in the
short term (I strongly believe that is a decision that we made
incorrectly when switching away from CVS, but git's windows support kind
of forced our hands, and the past is past.)
In the current world, there are enough hg and git users that I think
Mozilla should consider supporting both as first class citizens. The
proper way to do that would be deploying a git push server which
eliminates the need to do anything with hg on the client side.
I'm asking all these questions because I'm helping design the
replacement architecture for Try and the more optimal solutions that
will deliver a faster and better user experience tend to be easier to
implement for Mercurial and may partially preclude Git because, well,
Git just doesn't have the extensibility points as Mercurial (yay
extensions and dynamic programming languages). I'm not saying Git users
would be locked out: I'm just saying that having Mercurial running
locally and "proxying" certain actions through Mercurial (like Try
pushes) keeps more options on the table. It also means we have to
design, implement, and maintain 1 server interface instead of 2. From my
perspective, I like the server-side simplicity. But I'm also largely
ignorant of what Git users are going through. I'm trying to gauge
whether additional effort is warranted to placate the Git crowd. I'd
like to gauge things like e.g. how loudly people would scream if one day
I announced that pushing to Try will require a Mercurial extension. (If
that day comes, the carrot would be near instantaneous pushes with no
contention and infinite server-side scalability to millions of pushes.)
I'd be very curious to know more about these plans for the try server.
It would be very hard to judge how good or bad it would be for git users
without knowing more details.
But I'd like to question the trade-offs here. I actually believe
maintaining two server side solutions is absolutely the right choice, if
you consider the cost that we've been imposing on git users for the
previous years and the years to come. It's clear that git users are not
going to go anywhere, and our reliance on git is not going to decrease,
given projects such as Firefox OS which use git.
To answer your specific question, the workflow today barely even works,
so I guess nobody will scream if we introduce one more hurdle in this
workflow, but I'm not sure if that's the right long term move. (But
again, without knowing more about your plans, I cannot say for sure
whether those plans will add such hurdles in the short term.)
Another thing that I'd like to urge you to consider is first class
support for git users as you're focusing on building new infra around
hg. Historically we've considered a number of these issues as
after-thoughts, which has caused them to not get fixed ever. And also
note that it doesn't totally eliminate cool hg extensions and whatnot,
for example, with the git server model I described above, the git server
itself can happily run whatever hg extensions that it needs, without
making those bleed into the workflows of git users.
Last, but not least, thanks a *lot* for thinking about this before
deploying the new stuff. This makes me and other git users very happy! :-)
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
