From: Junio C Hamano Date: Wed, 21 Sep 2005 21:48:46 GMT Subject: Re: Please undo "Use git-merge instead of git-resolve in git-pull" Message-ID: <7vu0genlc1.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Linus Torvalds writes: > Local changes are a problem ONLY IF THOSE LOCAL CHANGES INTERFERE WITH THE > MERGE. True, sorry, and reverted. * Regardless of whatever else, we could detect when there is only one strategy applicable and bypass that check -- "reset --hard" should never happen in that case and 'git pull -s stupid' would regain the traditional behaviour and we should probably make this the default for 'git pull'. * Otherwise, if the user wants it to try multiple strategies, we need to detect the local changes in the tree that _could_ interfere with the merge more precisely. In order for that, we need to have a way to figure out the set of paths that _could_ potentially be involved in the merge. Once we have that set, we can just check if we have local changes on those paths, and the "restoring to the pre-merge state" currently done with "reset --hard" kludge could just restore those paths from the pre-merge HEAD. This is however harder than it sounds once we start allowing renaming merges. If the ancestor had A/foo, you kept it and have an addition of A/bar as a local change, and the head that is being merged renames stuff in A/ to B/A/, it is more likely than not that you would want to have A/bar moved to B/A/bar in your merge result. Once we go this route, the only thing it makes sense would be to make it responsibility for each merge strategy to preserve before starting its work and to restore after it has failed. * I thought you do not multitask and wonder why you are merging while you still have local changes, but that does not justify this regression.