Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > echo foo >> child1/testfile > perl -pi -e 's/tree/shrub/' child2/testfile >... > git-diff --binary > /tmp/patch > git-reset --hard > git-pull > git-apply /tmp/patch > > I might have gotten that slightly wrong, but I think I have the > general idea right. stg pull would help you in such a situation as well, but I see what you mean. Just like we have an explicit -m option to "checkout" to allow file-level merging of local changes, I think it is reasonable to hav an option that allows file-level merging of local changes when doing a pull that you _know_ will not conflict. When there will be a conflict between your HEAD and MERGE_HEAD even without your local changes, you somehow need to sort out the resulting mess that come from conflicts due to the branch diversion (i.e. log HEAD...MERGE_HEAD) and conflicts between your local change and what the other branch did. The resulting merge commit obviously needs to record resolutions only to the former and should not even record anything you did locally, conflicted or not. Which is a pain for the end user and giving them a way to revert to the state before this three-and-half way merge started also needs to be there. Unfortunately the only way to know if there will be a file-level conflict is to try one, and stashing away the current state just in case it conflicted is a performance penalty, so this probably should stay as an option just like "-m" to the "checkout". But the basic mechanism to do this three-and-half way merge is simple and I have no objection if somebody wanted to add such an option to "git pull". - 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