Johan Herland wrote: > 2. Merging without a worktree Eh, I am not a fan. I am thinking it might be better to use something like contrib/workdir to make a temporary worktree with its own index and HEAD in .git/tmp-merge-notes and let the conflict resolvers work there. Advantages: - easy to debug when something goes wrong - merge driver can take other unmerged entries into account - (if merging manually) the user is not at the mercy of the program. Instead of being forced to consider the conflicts in the order git wants, she can skip some and go back to them, look at how many there are before deciding to start work, resolve some, reboot to test a new kernel, resolve some more later, and visualize the result. - if the unmerged notes are very long, you might need a temporary file anyway - maybe some day a kind of rename detection could help cope with situations like propagation of notes after a rebase Disadvantages: - setting up a new git dir takes some time - a checkout with all notes would be insanely huge. So somehow one has to find an appropriate subset to check out. > Possible solution: Conflict resolvers: I think you can do an entirely in-index merge with ‘git read-tree’ and ‘git merge-index’. If you forbid the per-file merge driver to fail then this sounds like exactly what you’re talking about. In my opinion in the case of popping up an editor this is a cruel thing to do, but in the other cases it’s a good place to start. Hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html