0151976676
Detected while reading recent CHANGELOG entry but then decided to apply to entire codebase and docs since why not?
23 lines
1.3 KiB
Markdown
23 lines
1.3 KiB
Markdown
Well, I had to rethink how merges into adjusted branches should be handled.
|
|
The old method often led to unnecessary merge conflicts. My new approach
|
|
should always avoid unnecessary merge conflicts, but it's quite a trick.
|
|
|
|
To merge origin/master into adjusted/master, it first merges origin/master
|
|
into master. But, since adjusted/master is checked out, it has to do the
|
|
merge in a temporary work tree. Luckily this can be done fairly
|
|
inexpensively. To handle merge conflicts at this stage, git-annex's
|
|
automatic merge conflict resolver is used. This approach wouldn't be
|
|
feasible without a way to automatically resolve merge conflicts, because
|
|
the user can't help with conflict resolution when the merge is not
|
|
happening in their working tree.
|
|
|
|
Once that out-of-tree merge is done, the result is adjusted, and merged
|
|
into the adjusted branch. Since we know the adjusted branch is a child of
|
|
the old master branch, this merge can be forced to always be a
|
|
fast-forward. This second merge will only ever have conflicts if the work
|
|
tree has something uncommitted in it that causes a merge conflict.
|
|
|
|
Wow! That's super tricky, but it seems to work well. While I ended up
|
|
throwing away everything I did [[last Thursday|day_376__in_the_weeds]]
|
|
due to this new approach, the code is in some ways simpler than that
|
|
old, busted approach.
|