Just my 2c:

On Fri, Oct 31, 2014 at 6:48 AM, Gregory Szorc <g...@mozilla.com> wrote:

> a) Landing code to inbound, fx-team, aurora, etc
> b) Pushing to Try
>

I do (b) with |git push-to-try|. It's flakey sometimes, and I've always
been somewhat superstitious about using it to actually push to inbound - so
I tend to just |git format-patch -pk| and |hg qimport| on a mercurial repo.
I would welcome better-supported / more-reliable tools.


> c) Fetching new commits
>

This is easy given the git mirror, and pretty orthogonal to everything else
in the thread.


> d) Collaborating/sharing commits with others, especially hg<->git sharing
>

I push a branch to github and point people to it.


> 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'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?


They're definitely annoying sometimes, but "good enough" that it's never
been a priority for me to press for improvements to them.


> (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 think improvements would be welcome.

Is moz-git-tools the de facto standard for Mozilla developers? Are there
> other competing tools?
>

I use moz-git-tools. I am not aware of competing tools.


> 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?
>

I have not.


> 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?
>

Pushing via local mercurial clones works fine for me for the most part,
mostly because stuff all gets serialized in inbound/central anyway, so
there isn't much lost by exporting patches at the last minute. I haven't
played with review board yet, but I'm slightly skeptical that this model
will work as well there. If our code review workflow gets SCM integration,
git integration will probably be important.


> 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.


That seems fine to me, as long as the workflow is tier-1, constantly
improving along with hg, and the git folks aren't left to fend for
themselves when something breaks. Git is a popular tool and it has certain
advantages over mercurial that are critical to my productivity. I think
that's true for enough people that we ought to give the same SLA to both
tools. This email is a great start.

Thanks for your tireless work on productivity,
bholley
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to