Import Bot?

[facebook]

Import Bot?

[sdwilsh]

Commits that have already landed:

• 0b11437
• c91a1d8
• 8930077

[fredemmott]

1. At the moment, it's an entirely separate system, though we'd like to change this.
2. Some projects explicitly list the files, though the most common approach is probably manually applying these patches.

[chrisui]

I too am exploring how we can use fbshipit to sync internal projects from our private monorepo to public open source repos. (It seems a bit odd to have such a one-way tool atm but maybe I'm missing the point!)

I was wondering if, since fbshipit seems to have first-class support for writing to git & github, both of my repos live within github (they do - one private, the other public) I could theoretically have two shipit scripts which independently sync each way?

Would fbshipit be able to detect the, potentially interleaving changes? We could even avoid that problem by always running both scripts together (in some "sync" event) so on each side you collect changes since last sync and then apply diff in each direction.

@fredemmott @skevy

[fredemmott]

ShipIt does not support two-way sync, and it's not something we're particularly likely to work on; a single source of truth simplifies a huge number of problems.

That said, if you make it possible to change the tracking line added to commit messages and use a different one for each direction, skip if one's already present for the direction you're already going in, it will basically work - but it would probably be extremely time-consuming to debug and fix if the sync breaks in one direction only at some point and you keep pushing out patches in the other.

That said, it would be reasonable to use this approach if pull requests are merged to the internal repo instead of trying to have a true two-way-sync, i.e:

Pull requests could either be directly pushed by shipit to your internal repo (assuming it's Git or you send a PR for #1 :p):

• have new shipit script with github as source, internal repo as dest
• run shipit with --source-branch=pull/PR_NUMBER/head (https://help.github.com/articles/checking-out-pull-requests-locally/) and either:
  • do the differing identifier lines mentioned above
  • run with --skip-push, and with some other script, export the patch, amend it to remove the identifier, and land to your internal repo as normally
• you'll want your filter function, an additional phase, or a separate script to add 'fixes #nnnn' to the commit message so that github closes the PR when it lands

[sdwilsh]

I'm actively working on this internally as we speak. Expect the bulk of the code to land today or tomorrow.