On Mon, Oct 01, 2012 at 08:13:21PM -0500, Matt McClellan wrote: > We had an issue at our organization where changes were reverted when a > user was merging his local repo with the remote repo changes. The > merge conflicted and he unstaged all the changes that were not a > conflict, he then resolved the conflict and added just the conflicted > file and committed. The end result was that he reverted every change > from his last pull of the remote to his merge point. The problem I'm > having how hard it is to see this problem as both git show and git log > on the merge commit do not show any reverted files. It was found by > diffing his commit to each of the parents and seeing the opposite of > what we expected in the patch output. > > Anybody have ideas how we can prevent these mistakes? While we are > going to do more training, a hard stop that wouldn't even let these > make it to remote would be preferred. The problem is that from the remote's perspective, it is too late. These unstaged paths look exactly as if they were simply resolved in favor of the "ours" side of the merge. The remote does not even see that they had conflicts, but only that the path from one side was taken over the other. If it wanted to be careful, it could recreate the merge and notice that they did not, but even that will lead to some errors. For example, resolving another conflict may result in a situation where a change in another file becomes unwanted and is dropped. So I think any kind of receive hook to prevent these mistakes from being propagated is going to run afoul of legitimate cases. You'd do much better to work on the UI of the resolution workflow to prevent the mistake from happening in the first place. > I've done this using git add --interactive then reverting a files > changes, though the actual crime was done using egit staging tool. It > seems the command line won't let you unstage changes but gui tools and > interactive tools seem to allow it. You can do "git checkout HEAD <path>" from the command-line. But I would hope that the results of doing so are sufficiently obvious. Doing something like "git reset" is much more subtle, but it is reasonably well-known as a dangerous command, and I hope we are not encouraging it to new people. Doing a full revert of a path during merge resolution is probably fishy. It might make sense for "git add -i" to warn about it (I haven't used egit's staging tool, but presumably the same thing would apply). Another place to catch your issue (assuming that an unstaging tool was used, leaving the modified contents in the working tree) would be to notice unstaged changes in the working tree when committing a merge. The problem with forbidding it is that it is also a legitimate thing to do (e.g., because you carry some local modification to a file that you do not want to commit), so it is not necessarily indicative of an error. But in theory you would see a giant list of unstaged changes in the commit message template. I wonder if that is less obvious when committing via egit. -Peff -- 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