Jeff King wrote:
>
> I took a look at this today.
Heh, now *my* procrastination is paying off :-)
> Hmm. I was about to write "so we need some clever way of integrating the
> interactive hunk selection with a 3-way merge". But I just had a
> thought: we should do it in the reverse order. We do the three-way merge
> into a temporary index, and then ask the user to apply the result of
> _that_ tree into the working tree. Or maybe I am missing something else
> obvious and you can enlighten me.
I think that is the correct way to go about it from the user's POV.
He would be confused if the patch applied to WT/index were different
(because of a later merge) from the hunks he chose in the -p loop.
However, there's the issue of merge conflicts. Some options I can
think of are
1) refuse to work in the face of merge problems
2) stash requires a clean WT, so we can move the user's index out of
the way and use temporary index + WT to let the user resolve the
conflicts
3) require both clean WT and index so we can simply use the repo to
resolve
(The first one isn't quite as restrictive as it sounds; the user can
always apply on top of a clean HEAD, fix conflicts and re-stash, thus
doing a "stash rebase".)
> 1. For --index mode, it actually invokes add--interactive twice. It
> would be nice to do both passes at the same time, but I don't think
> it is possible with the current add--interactive infrastructure.
Note that the 'git stash -p' in next always stashes the index whole,
so the "easy" way might simply be to also unstash the index whole (if
requested).
The changes will usually still be available in the worktree
application, because the 3-way merge is between base and HEAD on one
side and base and worktree-stash on the other side.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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