On 5/1/2013 2:15 PM, L. David Baron wrote:
On Saturday 2013-04-27 08:26 +1000, Nicholas Nethercote wrote:
On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen <rya...@gmail.com> wrote:
-In the event of a long tree closure, the last green changeset from m-i will
be merged to inbound2 and inbound2 will be opened for checkins.
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2? Would I
need to have an up-to-date inbound2 clone and transplant the patch
across? Or is it possible to push from an inbound clone?
For what it's worth, what I'd do is qpop the patch, pull the tip of
inbound2 into my inbound clone and update to tip, qpush and qfin the
patch, and then "hg out -rtip inbound2" (and after checking it's
right), "hg push -rtip inbound2".
I wouldn't do anything involving bookmarks; the way of checking that
I'm pushing the right thing is to run "hg out" before "hg push" (as
one should always do... and as I don't know how to do in git).
$ git log HEAD..origin/master
However, this will compare the differences based on what the local Git
repository knows about. To ensure it is up to date, you'll need to fetch
the remote first:
$ git fetch origin
$ git log HEAD..origin/master
Even then this isn't entirely the same as `hg out`: this just tells you
which commits are between the local and remote ref. It's possible some
of the {commits, trees, blobs} already exist on the remote. The actual
details of which Git objects will be pushed is worked out at push time.
There are low-level Git commands to get at this set. But, I'd argue the
commit delta is what you care about, not which raw Git objects need to
be sent over the wire.
Anyway, if you had a Mozilla Mercurial extension installed, you could
just run |hg land| and magic would ensue.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
