Intelligently rerun `nbdev_export` in `nbdev_merge` for more automated conflict resolution

[seeM]

I've had a few instances now where notebook conflicts were resolved but where the modules and/or _modidx were still in a conflicted state. We might be able to run nbdev_export in the merge driver to fix that. I haven't yet thought about how complicated the logic would need to be.

[jph00]

@seeM is the logic as simple as this?: if there are no conflicted notebooks, then run nbdev_export

Or alternatively - would we always want to try to run it? Is there a reason we ever wouldn't?

[seeM]

Good questions. One possible issue with always running is that the conflict markers would be excluded from exported modules since they’re markdown cells, so it would hide conflicts.

Exporting only notebooks without remaining conflicts wouldn’t have that issue. If we’re only exporting certain notebooks though, we might have issues with notebooks that export to multiple modules or multiple notebooks exporting to one module.

Alternatively, we could try to make export retain conflicts then always run it?

[jph00]

One possible issue with always running is that the conflict markers would be excluded from exported modules since they’re markdown cells, so it would hide conflicts.

That might be OK though - because you'll know that the source NB has a conflict. And once you've fixed that, you just export.

[seeM]

Hmm yea that makes sense. Let's try it out. I'll make a tiny PR. We can always roll back if it doesn't work well

[seeM]

Actually it's a little trickier because merge runs per-file. We'd need some way of skipping merging .py files and instead use the exported ones. Or some sort of post-conflict hook that exports a single time after everything else

[jph00]

For .py files can we just always use an "ours" strategy if they are exported from a notebook (i.e they have a cell marker somewhere in them)?