{"thread":{"id":"9260","subject":"Teach git-gui about merging around modified files?","startedAt":"2007-07-27T17:03:47Z","lastAt":"2007-07-29T09:04:31Z","messageCount":3,"participants":["Brian Downing","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48806","messageId":"20070727170347.GX21692@lavos.net","threadId":"9260","inReplyTo":null,"subject":"Teach git-gui about merging around modified files?","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-07-27T17:03:47Z","receivedAt":"2007-07-27T17:03:47Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"\"git merge\" will happily merge a change with modified files in the tree\nas long as the merge doesn't touch any of them. However, it appears\n\"git gui\" won't even try if there are modified files at all.\n\nHow hard would it be to fix this, or is this an intentional choice?\nI realize that commiting even untouched files before a merge is safer,\nbut I'm tasked with migrating some CVS users to Git, and I'd prefer\nto be able to introduce the new Git workflow slowly.\n\n(I'm happy enough with disallowing merges that actually touch modified\nfiles, so I'm not looking for any kind of in-working-directory merge\nlike some others were. I'd just like the \"git merge\" behavior to work\nin git-gui.)\n\n-bcd\n"},{"id":"48960","messageId":"20070729073652.GN20052@spearce.org","threadId":"9260","inReplyTo":"20070727170347.GX21692@lavos.net","subject":"Re: Teach git-gui about merging around modified files?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-29T07:36:52Z","receivedAt":"2007-07-29T07:36:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brian Downing wrote:\n> \"git merge\" will happily merge a change with modified files in the tree\n> as long as the merge doesn't touch any of them. However, it appears\n> \"git gui\" won't even try if there are modified files at all.\n\nYes. That is actually intentional...\n \n> How hard would it be to fix this, or is this an intentional choice?\n\nIts not hard to fix. I just did it in a patch that would be:\n\n lib/merge.tcl | 12 +-----------\n 1 files changed, 1 insertions(+), 11 deletions(-)\n\nand we all know deleting more lines is good, but after I made the\npatch and started testing it I remembered exactly why I don't allow\nyou to merge with modified files.\n\nIf you merge and get conflicts you cannot abort to your pre-merge\nstate safely by just doing a `git reset --hard` (or git-gui's own\nbuiltin action that does the same) as you will toss your own not\nyet committed changes too. You really need to save those changes\noff first.\n\n> I realize that commiting even untouched files before a merge is safer,\n> but I'm tasked with migrating some CVS users to Git, and I'd prefer\n> to be able to introduce the new Git workflow slowly.\n> \n> (I'm happy enough with disallowing merges that actually touch modified\n> files, so I'm not looking for any kind of in-working-directory merge\n> like some others were. I'd just like the \"git merge\" behavior to work\n> in git-gui.)\n\nWhat do you do when the merge goes badly on the command line\n(lots of conflicts, but none to the files you have modified),\nand you want to get back to your pre-merge state? You can't,\nthere's no state saved for git to reset back to.\n\nReally what you want to do here is stash your local changes away,\nthen do the merge, and after the merge is successfully completed\napply the stash back onto your working tree. Because then if the\nmerge goes badly you can `git reset --hard && git stash apply`\nto bring back your prior state.\n\nSo until git-gui plays along nicely with git-stash (can save\nand apply to it) I'm going to continue to disallow merging with\nuncommitted changes. Its just not a smart thing to be doing.\n\n-- \nShawn.\n"},{"id":"48968","messageId":"20070729090431.GO20052@spearce.org","threadId":"9260","inReplyTo":"20070729073652.GN20052@spearce.org","subject":"Re: Teach git-gui about merging around modified files?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-29T09:04:31Z","receivedAt":"2007-07-29T09:04:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> Brian Downing wrote:\n> > \"git merge\" will happily merge a change with modified files in the tree\n> > as long as the merge doesn't touch any of them. However, it appears\n> > \"git gui\" won't even try if there are modified files at all.\n> \n> Yes. That is actually intentional...\n> \n> If you merge and get conflicts you cannot abort to your pre-merge\n> state safely by just doing a `git reset --hard` (or git-gui's own\n> builtin action that does the same) as you will toss your own not\n> yet committed changes too. You really need to save those changes\n> off first.\n\nI felt bad about my original response to this thread. Telling a\nuser that their workflow is broken and should be changed is not\nvery nice, and not user friendly.\n\nSo I just spent a couple of hours trying to teach git-gui to first\nsave off your index and working directory, then run the merge, and\nduring abort let you restore things even if they weren't committed.\n\nDuring testing I learned that you can't merge if you have any\nstaged but uncommitted changes. If you try git-merge-recursive\njust aborts and refuses to execute the merge, even if the file\npaths aren't in conflict and won't require a file level merge.\nThe issue is the files are staged in the index and would commit\nas part of the merge commit, rather than staying out until after,\nso the merge driver is really doing the right thing here.\n\nI'm still convinced that merging while you have uncommitted changes\nin the working directory is really bad. Its nearly impossible\nto recover from a conflict and get back to pre-merge state, and\nits also confusing to resolve conflicts because your unstaged but\nmodified files are still showing in the status.\n\nI'm going to shelve this work until post 0.8.0 and try to rework\nit using git-stash as part of git-gui 0.9.0. Ideally you should\nbe able to stash your work before merging, and unstash after the\nmerge is complete.\n\n-- \nShawn.\n"}]}