Re: 'git notes merge' implementation questions

[Johan Herland <johan@herland.net>]

On Wednesday 21 April 2010, Jonathan Nieder wrote:
> 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.

Thanks, I'm definitely coming around to the idea that having the user freely 
resolve conflicts in a temporary worktree (that preferably contains only the 
conflicting notes) is better than trying to resolve conflicts _without_ a 
worktree.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net