Hello all. I have observed some strange behaviour when exiting a custom merge driver that I was wondering if there’s any reason for — I think it may be a bug but I’ll leave that to you to decide. I’m configuring that merge driver to exit during a merge at the first sign of conflicts — the exact nature of the rules for the decision to exit early isn’t too important I think though so given it’s ‘work stuff’ I’ll leave some details out. Here is my current understanding of how the ort strategy will deal with this. - Ort runs the merge driver with the parameters for the current file to be merged - When the driver returns exit code 0 is returned it is treated as having no conflicts - When the driver returns exit code 1-128 is returned it is treated as having conflicts - When the driver returns exit code 129+ is returned it is treated as some kind of error scenario Then subsequently - If all files returned exit code 0 during the merge git will return exit code 0 i.e. no conflicts - If any file returned exit code 1-128 during the merge git will return exit code 1 i.e. conflicts - At any time if the driver returns 129+, git will stop merging and return exit code 2 i.e. error? However, when setting up a criss-cross merge scenario and ‘short circuiting’ the merge during an ancestor merge, I get exit code 134 Here’s a couple of quick scripts that help recreate the situation https://gist.github.com/mattcree/c6d8cc95f41e30b5d7467e9d2b01cd3d The logs also show ``` Assertion failed: (opt->priv == NULL), function merge_switch_to_result, file merge-ort.c, line 4661. ./run-recursive-merge.sh: line 162: 78797 Abort trap: 6 git merge $featureC --no-ff --no-commit ``` I thought it might be worth raising as a bug here but I’m not too sure really — I suppose the short circuiting logic I have introduced may not be a desirable use case from the git elders point of view, but I reckon the difference in behaviour depending on whether it’s an ancestor merge or a final merge seems to indicate to me that this is not intentional. Hopefully someone knows a bit more about this.
