I don’t understand code editors that think they know when to commit changes “better” than I do.
GoLand is guilty of this. I just finished resolving merge conflicts, but instead of letting me make sure the resolved conflicts actually build and pass the test, GoLand just commits them as soon as I’ve finished picking the hunks I want to use. This means any fixes I need to make cannot go into the merge commit. That commit is now unstable.
One could argue that this is the proper way to do things, that the merge commit should only contain conflict resolutions and nothing else. I don’t agree. I’m bound to make mistakes while resolving conflict, and I want to make sure what I’m committing is actually working code. It probably doesn’t matter in the grand scheme of things, and it wouldn’t be the first time I make a commit with dodgy code. But I’d like to reduce the number of times that happens if I possibly can.
Besides, conflicts in Go imports or module versions I can usually fixed by running tools. I tend to resolve these conflicts quickly, expecting to get errors and duplicates that I can fix with a couple of commands (they usually need to be formatted anyway). I can’t do this if the code editor decides when to actually commit the changes.
Stage the resolved conflicts all you like, but let me actually commit them when I say so.
✍️ Reply by email