Re: 'git notes merge' implementation questions

[Jonathan Nieder <jrnieder@gmail.com>]

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