partial stash, reversed-merge, and file modifications

I'm pretty happy about Git in general, but for two situations where I've found workarounds, which both have the same problem, which is that they "touch" files unnecessarily:

* First case: merge into a dirty tree.

I often want to "git pull" into a tree that's dirty. I know many people find this to be heresy, but for various reasons, I have a few trees that are pretty much always dirty and where I want to pull anyway without ever wanting to commit those changes.

The simplest solution I found is:

  git stash; git merge --ff-only; git stash apply; git stash drop

Problem with it: this will needlessly "touch" all the files which are locally modified but aren't affected by the merge. So a subsequent "make" can easily end up taking a lot more time than needed.

A simple solution to this problem would be to only stash those files which conflict:

  git stash save --only-some-files $(git merge 2>&1 | sed -ne 's/^	//p')
  git merge --ff-only; git stash apply; git stash drop

but of course the "--only-some-files" option to "stash save" doesn't exist. And writing an equivalent script is pretty painful.

* Second case: merge with reversed parents

The order of parents in a merge is sometimes important. Say you're in your branch "newfeature" and you want to install it into "master", you could do it this way:

   git merge master; <..make; check; push..>

but that gives you a history where the first parent is your feature branch and all the changes made to master in the mean time look like secondary changes. This is probably OK seen from "newfeature" but if you push this to "master", it will look odd on "master".

So instead, you'll want to do what I call a "reversed merge":

  git checkout master; git merge newfeature; <..make; check; push..>

Now the history tree is right. Good. But beside it being sightly more cumbersome, the main problem with it is that, again, this will needlessly "touch" all those files that are modified by "newfeature" but not by "master" (compared to the ancestor). So again, the subsequent "make" can take a lot more time than needed.

I'd love to either hear about ways to avoid/reduce this problem with current Git, or else to see some new features added to Git to reduce/solve those problems.

        Stefan