On 10/31/2014 06:48 AM, Gregory Szorc wrote:
a) Landing code to inbound, fx-team, aurora, etc
> b) Pushing to Try
From what I recall, the default moz-git-tools way is to have a clone for
each repository. This implies that you need one hg work directory per
target branch.
I changed the moz-git-tools locally, such as I only have to add an hg-path
to the target branch into the repository. Then in git I use the tracking
branches name to find the name of the repository in which I want to push.
$ git try-push …
Push to try on top of origin/master
$ git fetch origin inbound
Fetch mozilla-inbound
$ git rebase --onto origin/inbound origin/master
Replay my branch on top of mozilla-inbound, without taking any
patches which exclusively landed on mozilla-central
$ git branch -u origin/inbound
$ git hg-push
Push to mozilla-inbound
c) Fetching new commits
This depends when, if I am working with git I either fetch all branches from
gecko-dev, or just one branch at a time.
$ git fetch origin
or
$ git fetch origin master
The problem in fact comes from pushing new commits, as the hg repository is
automatically updated when I am pushing a commit, which means that a push is
way too slow.
d) Collaborating/sharing commits with others, especially hg<->git sharing
Never done, if I want to share some ongoing work, I push to github.
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.)
This is a pain point is when you have to push, I often forget to push
something just because it takes too much time to update the hg repository,
and that I already switched to work on something else.
Is moz-git-tools the de facto standard for Mozilla developers? Are there
other competing tools?
I think moz-git-tools is an ad-hoc solution which is accepted by most Gecko
developers which are using git.
Does anyone use hg-git (it has gotten *much* faster in the past year thanks
to Facebook's investment)?
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?
At the end of 2011, I made a server for pushing changes seamlessly, without
requiring any hg work-directory hosted locally (
https://github.com/nbp/git-hg-bridge ). I did not changed it to use
gecko-dev, because we are not sharing incremental updates of the mapfile.
As it is based on hg-git, it was capable of sending merge-commits to try,
which is useful when you have long live branches. One of the reason I
stopped using it, is that hg-git took minutes to convert git commits to
changesets. Also, maintaining hg-git was time consuming, in bad moments. I
have not tried any recent version of hg-git.
Overall, how happy are you with your Git fetch/push workflows? Short of
switching the canonical repositories to Git, what do you need to be more
productive?
With a custom moz-git-tools, git-bz, and bunch of aliases, a better
experience at rebasing (compared to hg queues), developing on top of master,
pushing on top of inbound. Git solved all the problem I had when I started
using Mercurial, and it was less of a pain to use Git than loosing work with
Mercurial.
So, Mercurial is not an alternative from my point of view. As such, the
workflow is not an alternative either.
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.
To be honest, I think that keeping a mercurial work-directory for doing any
action is just a waste of time / disk-space, especially since we have to
pull changes twice for being able to push, find the the right parent if we
want the patches to apply correctly, apply the patches with hg-queues, and
deals with hg error messages.
It also means we have to design, implement, and maintain 1 server interface
instead of 2.
Do we have 2 server interface today?
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.
How such extension would prevent Git users from pushing to Try? Can you
provide more detail? If this extension locks everybody under Mercurial then
I do not think this would be a wise choice.
The question I have is, how long should we be waiting before providing a
sane solution for git, considering the 388 forks (as of today) of gecko-dev
on github?
--
Nicolas B. Pierron
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
