Re: git add -p with unmerged files (was: git add -p with new file)

From: Jeff King <peff@peff.net>
Date: Dec 13, 2016, 19:49 UTC
Message-ID: <20161213194859.eoztbojnp4veaozc@sigill.intra.peff.net>
In-Reply-To: <98817141-fa57-7687-09c4-dc96419d8a35@gmx.net>

On Tue, Dec 13, 2016 at 08:21:59PM +0100, Stephan Beyer wrote:

> While we're on the topic that "git add -p" should behave like the
> "normal" "git add" (not "git add -u"): what about unmerged changes?

I agree that's a related part of the workflow, though the implementation is a bit harder.

Show 6 quoted lines

> When I have merge conflicts, I almost always use my aliases
> "edit-unmerged" and "add-unmerged":
> 
> $ git config --global --list | grep unmerged
> alias.list-unmerged=diff --name-only --diff-filter=U
> alias.edit-unmerged=!vim `git list-unmerged`

You might like contrib/git-jump for that, which makes it easier to go to the specific spots within files.

When "git jump merge" produces no hits, I know I've dealt with all of the conflicts (textual ones, anyway). I do often want to run "git add -p" then to review the changes before staging.

I think what is most helpful there is probably "git diff HEAD" to see what the merge is bringing in (or the cherry-pick, or "am", or whatever). If I wanted "add -p" to do anything, I think it would be to act as if stage 2 ("ours", which should be the same as what is in HEAD) was already in the index. I.e., show the diff against that, apply any hunks we select, and store the whole thing as stage 0, losing the unmerged bit.

When you select all hunks, this is equivalent to "git add unmerge-file". If you choose only a subset of hunks, it leaves the unselected ones for you to examine later via "git diff". And if you choose none, it should probably leave unmerged.

That's just a scheme I thought up, though. I've never actually tried it in practice.

-Peff