Repository navigation
attempt-backport: enable 3-way merge for git am - #117
Conversation
We've seen a lot of patches not applied cleanly by the bot, which in fact should have landed without trouble, at least with 3-way merges enabled. This trivial change enables fallback to 3-way merge when a patch doesn't apply cleanly when running `git am`.
|
It should be safe to add this, but I'm not still 100% sure that this is all that is needed for safe, automatic conflict resolution. |
|
I'm pretty sure its not all that's needed. If master has A, B, C on it, and C depends on B, then C won't cherry-pick clean, and will get marked as not applying, but when the staging branch is built from A, B, and C, it will pick clean. This is how the check is made, right, a single commit cherry-pick/ If it was made by cherry-picking every commit, in order, from master that hasn't been labelled by a person as don't land, that might work because its closer to how the tools are used when backporting, and supports dependencies between commits. |
|
Okey, so it's probably not going to be rock solid after these changes either. But we agree that falling back to 3-way merges won't do any harm or be even more incorrect than the bot is currently, right? |
|
Yes |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
4 participants
We've seen a lot of patches not applied cleanly by the bot, which in fact
should have landed without trouble, at least with 3-way merges enabled.
This trivial change enables fallback to 3-way merge when a patch
doesn't apply cleanly when running
git am.Should we give this a try before possibly disabling the attempt-backport labels?
Refs #116
/cc @mscdex @MylesBorins @Fishrock123