W dniu 19.02.2011 00:17, Jonathan Nieder pisze: >>> "git reset --merge" will remove local changes marked with "git add", >>> under the assumption that they were part of the conflict resolution >>> and thus should be cleared away. >> >> Didn't know that (one probably shouldn't merge with uncommitted/local >> changes anyway). git-reset.txt mentions it, but there's no explicit >> warning. > > Care to write a patch? I tried but gave up :( >> Is it possible to recognize that you have something more than what >> was cause by the merge/cherry-pick? > > I suppose it depends what you mean. I see at least two distinct > problems to solve: > > A. "undo" facility to recover from an ugly cherry-pick That's what I meant. There's a 'git merge --abort', the same should be available for cherry-pick. If I understand correctly, this requires changes to cherry-pick to set ORIG_HEAD? > This one is what reset --merge is for. The idea is that after > spending a little while trying to make something good out of a > mess, you say, "oh, bother, let me get back to where I started". Maybe 'git cherry-pick --abort' could do 'reset --merge' internally. You would not have to remember "ok, for merge I can do --abort, but for cherry pick I must do reset --merge". > So in this case it really does make sense to back out any changes > you marked with "git add" after the cherry-pick, since they were > part of the messy resolution process. If there had been any > changes registered before the cherry-pick, the cherry-pick would > have just failed without making a mess. Indeed, cherry-pick won't start if there are any stashed changes. I wasn't aware about this. Which is a bit strange: why cherry-pick behaves differently than merge? (merge allows staged changes when merging, cherry-pick doesn't). Shouldn't they work the same, i.e. allow merge or cherry-pick if the changes are not conflicting? Anyway, cherry-pick refuses to work if you have staged changes, but still doesn't mind local unstaged changes. Which makes possible following case: do some local hacking, do not stage yet cherry-pick commit with merge conflicts try to resolve them, adding local changes in meantime give up and try to abort with 'git reset --merge' In result your local changes will be lost. I don't know how real such situation is, but maybe git could/should prevent it? For example by saying "you're trying to abort merge, but it will also revert your local changes from before the merge". > A patch in flight makes "git cherry-pick" print advice for this case > when it encounters conflicts (thanks!). Nice :) -- Piotr Krukowiecki -- 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