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
--
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