reminder: fx-team is the new (front-end) inbound

Gregory Szorc gps at
Sun Aug 4 01:44:48 UTC 2013

On 8/2/2013 12:30 PM, Ehsan Akhgari wrote:
> On 2013-08-02 1:47 PM, Gregory Szorc wrote:
>>> Merge conflicts will definitely happen more in the future, I don't think
>>> it's reasonable to expect everybody to have a mapping of what they (or
>>> others) have landed in which branch all the time.
>> Detecting code merge conflicts can be automated. Whether it can be done
>> so in a manner that is efficient for everyone to continuously run
>> remains to be seen.
> Detecting merge conflicts can only be usefully performed when attempting
> a merge, since before that you won't know what the two sides of merge
> will look like (i.e., a conflicting patch may be backed out before the
> merge happens.)

I think assuming the tip of an integration branch merged into central's
tip is a useful approximation of a future merge. If a patch lands in an
integration repository, it will eventually make its way into central, no?

>> One of the benefits of having a unified repository is that clients will
>> possess all of this information locally and thus will more easily be
>> able to identify merge conflicts.
> When you're merging, the merge parents have to be in your local repo
> anyway, so a unified repo wouldn't be particularly helpful here.

Kinda sorta. A benefit of a unified repo is that changesets can be known
sooner (since changesets can be pulled in before merge time). This would
allow merge conflicts to be detected earlier.

>> I've filed a bug [1] against my mozext Mercurial extension to track
>> implementing merge conflict detection. I'm optimistic it will be
>> possible to detect at push/pull time. Worst case we can operate a
>> service/command that the sheriffs or anyone can use to detect merge
>> conflicts early, before things blow up at merge time.
> Hrm, what's wrong with just running hg merge?  :-)

Nothing. However, I think the earlier everyone is aware of future merge
conflicts the better. Currently, merge conflicts aren't detected
until... merge time. This results in fire drills and/or tree closures,
which can impact a bunch of people and hinder productivity.

I think it would be useful if people were made aware of future conflicts
as early as possible, before it became an issue. I imagine sheriffs
would want to know if fx-team and inbound will fail to merge into
central so they can alert the conflicting patch developers before tree
closures occur. Also, if I were working on a patch that wouldn't merge
cleanly on inbound, I think I'd like to know about that ASAP, preferably
at qref time. Otherwise, I may go through an extra review cycle in order
to resolve merge conflicts.

In my ideal world, our tools would be smart enough to alert developers
to possibly conflicting changes others are making. For example, if you
are touching file X and I have a try push touching file X, the tools
would be like "hey, did you know gps is touching file X in bug 123456?
[you might want to see what he's up to!]." I believe this would result
in less overall developer effort due to fewer conflicting changes. I
view early merge conflict detection as a step towards this ideal since
it would enable patch authors to detect conflicts against expected
future merges.

More information about the firefox-dev mailing list