Awesome explanation by jdep

Hacking on B2G moz-central

<jedp> getting started https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Preparing_for_your_first_B2G_build
<jedp> slightly out of date, but basically the right steps: https://gist.github.com/jedp/3778932
<jedp> where it says mozilla-inbound, use mozilla-central instead
<jedp> a file called .mozconfig
<jedp> a b2g desktop mozconfig http://www.pastebin.mozilla.org/2752657
<jedp> instead of console.log … used dump("some message\n")
<jedp> to build
<jedp> ./mach build
<jedp> no more make -f client.mk
<jedp> don't do that
<jedp> just "./mach build"
<jedp> however
<jedp> if you are building the b2g18 branch
<jedp> say you put your new code in toolkit/identity
<jedp> ./mach build toolkit/identity
<jedp> for the record
<jedp> if you need to do this on b2g18
<jedp> cd ../build_dir ; make -C toolkit/identity ; cd ..
<jedp> s/cd ../cd -/
<jedp> http://www.pastebin.mozilla.org
<MrDHat> http://www.pastebin.mozilla.org/2752704
<jedp> apt-get install ccache
<jedp> ?
<jedp> path/to/b2g -profile /path/to/gaia/profile -jsconsole
<jedp> b2g will be in your dist dir: $BUILD/dist/b2g
<jedp> https://developer.mozilla.org/en-US/docs/Mercurial_Queues
<jedp> https://gist.github.com/jedp/3778932#prep-steps-setting-up-mercurial-queues
<jedp> steps are like this
<jedp> first, make a new patch
<jedp> > hg qnew my-patch
<jedp> = mercurial! make a new patch in my queue, and call in 'my-patch'
<jedp> at this point, all your changes will go into that patch file
<jedp> well, almost
<jedp> to get changes added to the patch, say:
<jedp> > hg qrefresh
<jedp> if you say 'hg qdiff', you see local changes to the repo
<jedp> oops
<jedp> if you say 'hg diff', you see local changes to the repo
<jedp> then you do:  hg qrefresh
<jedp> after this, say 'hg diff', and there will be no changes
<jedp> but when you say 'hg qdiff', you'll see all the changes applied by the patch
<jedp> or patches
<jedp> this is nice
<jedp> when you './mach build' again, your patches will be magically applied
<jedp> so if you patch is confined to toolkit/identity, you say './mach build toolkit/identity'
<jedp> so how do you rebase?
<jedp> you can't just 'hg pull'
<jedp> so you do this:
<jedp> > hg qpop
<jedp> > hg pull -u
<jedp> # which is shorthand for 'hg pull; hg update'
<jedp> > hg qpush
<jedp> conflicts?
<jedp> but what will happen - it will "reject" your patch
<jedp> when that happens, it creates a .rej file next to the file that was rejected
<jedp> edit your file and the .rej file and work it out :(
<jedp> once you fix the conflict
<jedp> conflicts
<jedp> you say "hg qrefresh"
<jedp> these are the ones to get to know:
<jedp> hg qrefresh
<jedp> ./mach build your/stuff
<jedp> hg qpop
<jedp> hg pull -u
<jedp> hg qpush
<jedp> so you have two patches, A and B, and B depends on A
<jedp> first you would have said:
<jedp> > hg qnew A
<jedp> and then you do stuff, and you type 'hg qrefresh' now and then ...
<jedp> so then
<jedp> > hg qnew B
<jedp> now you have two patches in your queue
<jedp> you can see your queue like so:
<jedp> > hg qapplied
<jedp> i think it will print out like this
<jedp> A
<jedp> B
<jedp> so if you have to change A
<jedp> > hg qpop
<jedp> it'll say:  now at A
<jedp> make changes for A
<jedp> > hg qrefresh
<jedp> > hg qpush
<jedp> it'll say :  now at B
<jedp> when you say 'hg qpush', it pushes the patch that was last on top
<jedp> first, to know what patches are available, you say:
<jedp> > hg qseries
<jedp> A
<jedp> B
<jedp> C
<jedp> D
<jedp> E
<jedp> let's say you're working on A and D, but yesterday you had A and B
<jedp> if you're at A
<jedp> simply saying 'hg qpush' would push B, not D
<jedp> but you want D
<jedp> so:
<jedp> > hg qpush --move D
<jedp> it's easy to mess this up
<jedp> to pop everything:
<jedp> > hg qpop -a
<jedp> # maybe now you hg pull -u
<jedp> > hg qpush --move A
<jedp> > hg qpush --move D
<jedp> > ./mach build your/project
<jedp> simliar to git add:
<jedp> > hg qnew your-patch
<jedp> and if you create new files:
<jedp> > hg add path/to/your/file.js
<jedp> > hg qrefresh
<jedp> you don't ever push to mozilla-central
<jedp> instead you submt a patch for review on bugzilla
<jedp> after you get r+ (means "positive review")
<jedp> you set a flag to "checkin-needed"
<jedp> first it will land in mozilla-inbound
<jedp> and if that goes well
<jedp> then uplift to mozilla-central
- {Day changed to Thursday 1 August 2013}
<jedp> and then you are part of firefox
<jedp> i'll show you the try server - how to submit your patch to the build farm for testing
<jedp> btw, the 'try' server lets you build packages for different architectures
<jedp> it'll make your own Nightly