=== re: === The handling of a case where a pull decides to go ahead (because it does not have to touch the Makefile you have your codename updates in) but does not complete with real conflicts, is not as graceful as the other two cases (merge refusing to run at all without touching anything, or merge completes cleanly and makes a commit). You will be left with: - Paths that have local changes (index matches HEAD but work tree does not match the index --- like your Makefile); - Paths cleanly merged (index and HEAD are different but work tree already matches the index); - Unmerged paths (index has higher stage entries with <<</===/>>> files in the work tree); You, I and experienced users know what to do. Deal *only* with the last kind, mark them with "git add" after you are done with each of them, and make sure you do not say "-a" when committing the result, to exclude the first kind from the merge result. I've been wondering if we can make this safer for others. ===end=== I've gone over that carefully and I understand (I think) what you are saying. The first two are things that were not committed, and should stay that way (added or not) if they did not conflict. But they can get in the way if a merge (on other files) is needed. In an effort to "wonder" out loud, can you explain how to handle that with "mergetool"? For a dumb user like me, it just fixes some files itself (I guess kdiff is smarter than the normal merge logic) and presents me with a GUI for things I need to specify. This should naturally only go through files with conflicts because of those "<<</===/>>>" files present. So, what should I know/do? "Don't use -a"? If the idea is to commit the merged stuff but preserve the status of what I've added but don't want to commit yet, I'm at a loss. Using git GUI, it will be backwards: my additions show, but the freshly merged files are noticed as changes that could be staged. I want to un-stage the original, stage the merged files, commit, then re-stage the original stuff?! Looking again and what you wrote, I think you are not doing that at all. You would add the merged files to the index, carefully preserving the first kind. Is it possible/easy to do what I thought you meant at first: commit just the merged files, and leave the "unaffected" files still in the index and not committed? --John -- 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
