Hi Jed, That's a good point. I'm going to test what happens when there's a merge conflict and see how the tool works. I've also noticed that the rebase on line 244 is causing duplication of commits in the super-repo. -Jim On 5/23/14 11:33 AM, "Jed Brown" <[email protected]> wrote:
"Foucar, James G" <[email protected]> writes:
Hi Jed,
The merge would be done by whoever did the "single-repo-helper update-subrepo" command, presumably a code maintainer. That's assuming the conflict was caused by work that happened on the independent repo with work that happened in the super-repo.
The conflict could be "caused" by either side. In these cases, usually nobody is at fault, just a lack of out-of-band communication or an attempt to integrate features developed at different times. Committing the merge for an incompatible state is wrong. (Well, not wrong if you fix it before pushing.) But even if one side is "at fault", the best way to fix it could be on the other side.
If the integrator notices the problem before pushing and if they understand all the semantics handled by the script in the friendly case, they can manually repair. But now they don't have the support/consistency of the tool and it's easy to forget things. If they don't notice the problem, someone else needs to be able to diagnose what went wrong and either fix it or report and wait for the SE/integrator to fix it.