{"thread":{"id":"40074","subject":"partial stash, reversed-merge, and file modifications","startedAt":"2015-08-12T20:05:11Z","lastAt":"2015-08-12T20:05:11Z","messageCount":1,"participants":["Stefan Monnier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"267943","messageId":"jwvr3n8xptl.fsf-monnier+gmane.comp.version-control.git@gnu.org","threadId":"40074","inReplyTo":null,"subject":"partial stash, reversed-merge, and file modifications","fromName":"Stefan Monnier","fromEmail":"monnier@iro.umontreal.ca","sentAt":"2015-08-12T20:05:11Z","receivedAt":"2015-08-12T20:05:11Z","isPatch":false,"sender":{"key":"monnier@iro.umontreal.ca","avatar":null},"body":"I'm pretty happy about Git in general, but for two situations where I've\nfound workarounds, which both have the same problem, which is that they\n\"touch\" files unnecessarily:\n\n* First case: merge into a dirty tree.\n\nI often want to \"git pull\" into a tree\nthat's dirty.  I know many people find this to be heresy, but for\nvarious reasons, I have a few trees that are pretty much always dirty\nand where I want to pull anyway without ever wanting to commit\nthose changes.\n\nThe simplest solution I found is:\n\n  git stash; git merge --ff-only; git stash apply; git stash drop\n\nProblem with it: this will needlessly \"touch\" all the files which are\nlocally modified but aren't affected by the merge.  So a subsequent\n\"make\" can easily end up taking a lot more time than needed.\n\nA simple solution to this problem would be to only stash those files\nwhich conflict:\n\n  git stash save --only-some-files $(git merge 2>&1 | sed -ne 's/^\t//p')\n  git merge --ff-only; git stash apply; git stash drop\n\nbut of course the \"--only-some-files\" option to \"stash save\"\ndoesn't exist.  And writing an equivalent script is pretty painful.\n\n* Second case: merge with reversed parents\n\nThe order of parents in a merge is sometimes important.\nSay you're in your branch \"newfeature\" and you want to install it into\n\"master\", you could do it this way:\n\n   git merge master; <..make; check; push..>\n\nbut that gives you a history where the first parent is your feature\nbranch and all the changes made to master in the mean time look like\nsecondary changes.  This is probably OK seen from \"newfeature\" but if\nyou push this to \"master\", it will look odd on \"master\".\n\nSo instead, you'll want to do what I call a \"reversed merge\":\n\n  git checkout master; git merge newfeature; <..make; check; push..>\n\nNow the history tree is right.  Good.  But beside it being sightly more\ncumbersome, the main problem with it is that, again, this will\nneedlessly \"touch\" all those files that are modified by \"newfeature\" but\nnot by \"master\" (compared to the ancestor).  So again, the subsequent \"make\"\ncan take a lot more time than needed.\n\nI'd love to either hear about ways to avoid/reduce this problem with\ncurrent Git, or else to see some new features added to Git to\nreduce/solve those problems.\n\n\n        Stefan\n"}]}