Petr Baudis <pasky@xxxxxxx> writes: >> However, I think we may want to talk about "How to tell if your merge did >> not even touch your index nor working tree" somewhere in the manual. >> "When there are conflicts, these things happen" part talks about how to >> resolve conflicts, but when merge refuses to avoid losing local changes, >> the instruction in that part does not apply. > > I'm not sure if this is worth pondering about? The action would feel > rather obvious to me - get rid of the local changes somehow, either > committing them or stashing them or wiping them out. Is that worth > elaborating, or is there more to it? Oh, the necessary action is obvious. That's not the issue. You either forget about the merge and in that case your index and working tree is intact and you can keep going. Or stash to merge first. But what I was wondering was if we have given the users enough clues to tell if the above is the right action. If merge started and conflicted, then forgetting about it and keep going is _not_ the right thing, and the user needs to be able to tell these two very distinct cases apart. -- 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
