Subject: Re: [PATCH/RFC 0/2] git-gui: issues with merge tool series

From: "Shawn O. Pearce" <[email-masked]>
Date: Wed, 24 Sep 2008 10:48:23 -0700

Alexander Gavrilov <[email-masked]> wrote:
> On Wed, Sep 17, 2008 at 3:40 PM, Johannes Sixt <[email-masked]> wrote:
> > 1. The inability to stage a conflicted file by clicking the icon is
> >   *very* disruptive. The new menu entry "Stage Working Copy" is
> >   really only a workaround, and it shows.
> 
> I can see two ways to fix it:
> 
> 1) Allow that icon to work only if the diff is currently displayed,
> and also ask for confirmation if there are any conflict markers
> present.
> 
>    Problem: What should it do with modify/delete conflicts, which
> don't have any conflict markers?

I'm inclined to say we should just let the icon work like it used
to, stage the whole working copy.  That's exactly what it does on
a non-merge, and thus is what it should do on a merge.

As a safety feature we can scan the working copy for merge marks if
we are currently in a merge and prompt the user for confirmation
if it looks like they are merging an unmerged working copy.
 
> 2) Much harder: implement complete one-click undo. This involves
> saving information from the index somewhere, and forcing such items to
> remain in the 'staged' list, even if the index isn't different from
> the tree version any more.
> 
>    By the way, is there a simple way to re-create a conflict file from
> the saved multistage index entries?

Run git-merge-file after extracting the stages to temporary files.
You can also jam the stages back into the index with update-index
--index-info.

-- 
Shawn.