On 11/03/2014 07:43 PM, Gregory Szorc wrote:
On 10/31/14 11:03 AM, Ehsan Akhgari wrote:
Not sure if I follow. Are you suggesting that git users push to their
own vanilla git server, and then autoland comes around some time later,
converts that into hg, and tries to transplant the result? Why i
On 11/03/2014 06:37 PM, Gregory Szorc wrote:
On 10/31/14 7:21 AM, Ehsan Akhgari wrote:
On 2014-10-31 1:48 AM, Gregory Szorc wrote:
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
On 10/31/14 11:03 AM, Ehsan Akhgari wrote:
On 2014-10-31 12:51 PM, Gregory Szorc wrote:
All problems in computer science can be solved by another level of
indirection. The problem here is that Git users need to push to the
canonical Mercurial repositories (inbound, try, etc). You will be
hearing
On 10/31/14 7:21 AM, Ehsan Akhgari wrote:
On 2014-10-31 1:48 AM, Gregory Szorc wrote:
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 i
On Fri, Oct 31, 2014 at 02:03:35PM -0400, Ehsan Akhgari wrote:
> On 2014-10-31 12:51 PM, Gregory Szorc wrote:
> >As has been said on this list before, switching canonical to Git just
> >isn't going to happen. Valid reasons have been given before. But here's
> >a new one: we don't need to.
> >
> >I
On 31/10/2014 22:21, Ehsan Akhgari wrote:
>> 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/
On 31/10/2014 13:48, Gregory Szorc wrote:
> Does anyone use hg-git (it has gotten *much* faster in the past year
> thanks to Facebook's investment)?
In order to submit a patch (or is it called a pull request) to the
Addon-SDK I installed hggit (since all my other workflows are Hg).
Pulling and pu
Gregory Szorc writes:
> 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 u
On Thu, 30 Oct 2014, Gregory Szorc wrote:
Hey ho,
Let me give you my views on this as a relative newcomer in the source tree. I
started at Mozilla early 2014 and as an old open source contributor to and
maintainer of dozens of projects for many years I am deeply accustomed to
using git and th
Ehsan Akhgari wrote:
> The reason I and others go through this pain right now to avoid having
> to use hg more is increased productivity. [...]
For the record (and I'm currently a user of the git+github+moz-git-tools
cohort, so I'm me-too'ing here), I've occasionally tried the new hg tools,
sin
On 10/31/2014 11:03 AM, Ehsan Akhgari wrote:
> On 2014-10-31 12:51 PM, Gregory Szorc wrote: All problems in computer
> science can be solved by another level of
>> indirection. The problem here is that Git users need to push to the
>> canonical Mercurial repositories (inbound, try, etc). You will b
> From: "Ehsan Akhgari"
> To: "Gregory Szorc" , "dev-platform"
>
> Cc: "Nicolas Pierron"
> Sent: Friday, October 31, 2014 10:21:09 AM
> Subject: Re: Git -> Hg workflows?
>
> In the current world, there are enough hg and git us
On 10/31/2014 07:21 AM, Ehsan Akhgari wrote:
> 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
Sorry for the irr
On Fri, Oct 31, 2014 at 2:24 PM, Steve Fink wrote:
> On 10/31/2014 08:00 AM, Nicolas B. Pierron wrote:
>> On 10/31/2014 06:48 AM, Gregory Szorc wrote:
>>
>>> I'm interested in knowing how people feel about these "hidden hg"
>>> tools. Is
>>> going through a hidden, local hg bridge seamless? Satisf
On 10/31/2014 08:00 AM, Nicolas B. Pierron wrote:
> On 10/31/2014 06:48 AM, Gregory Szorc wrote:
>
>> 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 noti
On 30/10/14 22:48, 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 architec
Generally speaking, I use git for everything except pushing to inbound and try,
and I use moz-git-tools to intermediate my interaction with hg.
> a) Landing code to inbound, fx-team, aurora, etc
For this, I keep around hg repos for the repos I care about, which is m-c and
inbound right now, the
On 2014-10-31 12:51 PM, Gregory Szorc wrote:
As has been said on this list before, switching canonical to Git just
isn't going to happen. Valid reasons have been given before. But here's
a new one: we don't need to.
I think it's fair to say that the pain point for Firefox Git developers
*today*
On 10/30/14 10:48 PM, 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 architectur
On Thu, Oct 30, 2014 at 10:48 PM, 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
> replacem
On 10/31/14 9:51 AM, Gregory Szorc wrote:
All problems in computer science can be solved by another level of
indirection. The problem here is that Git users need to push to the
canonical Mercurial repositories (inbound, try, etc). You will be
hearing me say this a lot in the months ahead, but "Au
On 10/31/14 7:21 AM, Ehsan Akhgari wrote:
On 2014-10-31 1:48 AM, Gregory Szorc wrote:
> 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
Before I get to complaining (which I love to do), first let me say thank
you for all the amazing hard work you've put into improving the
developer experience! The improvements between when I started almost 4
years ago and now are nothing short of incredible.
I use git exclusively. The only time I
Let me try to answer at a high level first. I use git for all of my
workflows and
when I collaborate with other people on my team, we use git and github.
See, for instance:
https://github.com/unicorn-wg/gecko-dev/tree/multistream_rebase
So, I primarily need to engage with hg for the following ta
I cannot live without moz-git-tools. Let me explain.
> a) Landing code to inbound, fx-team, aurora, etc
I use "git bz attach" to attach patches to bugzilla and use checkin-needed.
> b) Pushing to Try
I use "git push-to-try". This command needs a local hg repo, so I need to
update it every time w
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-
On 2014-10-31 10:43 AM, Dirkjan Ochtman wrote:
On Fri, Oct 31, 2014 at 3:21 PM, Ehsan Akhgari wrote:
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 ser
On Fri, Oct 31, 2014 at 3:21 PM, Ehsan Akhgari wrote:
> 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
> anythi
- Original Message -
> a) Landing code to inbound, fx-team, aurora, etc
> b) Pushing to Try
I have a script that handles pushing a range of commits to the repository of my
choice. This script is essentially:
for id in ${range}; do
git show --unified=3 --id=${id} --format="${stuff}"
I use git day to day. I use hg primarily for landing code and "hg bzepxort".
On Fri, Oct 31, 2014 at 1:48 AM, Gregory Szorc wrote:
> I
> I'm interested in knowing how people feel about these "hidden hg" tools.
> Is going through a hidden, local hg bridge seamless? Satisfactory? Barely
> tolerabl
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 architectu
Thanks for sending this email! Some responses below..
On 31/10/2014, 1:48, Gregory Szorc wrote:
a) Landing code to inbound, fx-team, aurora, etc
b) Pushing to Try
My workflow involves exporting patches from git as flat text files and
then using qimport/push from a single hg pseudo-unified rep
Just my 2c:
On Fri, Oct 31, 2014 at 6:48 AM, Gregory Szorc 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 t
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 looki
34 matches
Mail list logo
