Stephan Beyer <s-beyer@xxxxxxx> writes: > 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? > > > 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` > alias.add-unmerged=!git add `git list-unmerged` > alias.reset-unmerged=!uf=`git list-unmerged`; git reset HEAD $uf; git > checkout -- $uf > > The "add-unmerged" alias is always a little scary because I'd rather > like to check the changes with the "git add -p" workflow I am used to. > > Opinions? For this, you would NEVER want to use "add -p" to pick and choose. By definition, while you are in conflicted merge, the path that had conflicts before you started the merge-y operation (be it "pull", "am -3", or "cherry-pick") did not have any change since HEAD, and "pick this hunk, drop that hunk" cannot be correct for the conflict resolution. "git diff" while conflicted will highlight what conflicted by showing the three-way diff (similar to "diff --cc" on a merge result) and after conflict is resolved you can view "diff HEAD" on the path to see what the merge brought in.