Brian Downing <bdowning@xxxxxxxxx> wrote: > "git merge" will happily merge a change with modified files in the tree > as long as the merge doesn't touch any of them. However, it appears > "git gui" won't even try if there are modified files at all. Yes. That is actually intentional... > How hard would it be to fix this, or is this an intentional choice? Its not hard to fix. I just did it in a patch that would be: lib/merge.tcl | 12 +----------- 1 files changed, 1 insertions(+), 11 deletions(-) and we all know deleting more lines is good, but after I made the patch and started testing it I remembered exactly why I don't allow you to merge with modified files. If you merge and get conflicts you cannot abort to your pre-merge state safely by just doing a `git reset --hard` (or git-gui's own builtin action that does the same) as you will toss your own not yet committed changes too. You really need to save those changes off first. > I realize that commiting even untouched files before a merge is safer, > but I'm tasked with migrating some CVS users to Git, and I'd prefer > to be able to introduce the new Git workflow slowly. > > (I'm happy enough with disallowing merges that actually touch modified > files, so I'm not looking for any kind of in-working-directory merge > like some others were. I'd just like the "git merge" behavior to work > in git-gui.) What do you do when the merge goes badly on the command line (lots of conflicts, but none to the files you have modified), and you want to get back to your pre-merge state? You can't, there's no state saved for git to reset back to. Really what you want to do here is stash your local changes away, then do the merge, and after the merge is successfully completed apply the stash back onto your working tree. Because then if the merge goes badly you can `git reset --hard && git stash apply` to bring back your prior state. So until git-gui plays along nicely with git-stash (can save and apply to it) I'm going to continue to disallow merging with uncommitted changes. Its just not a smart thing to be doing. -- Shawn. - 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
