Quoting Karl Hasselström <kha@xxxxxxxxxxx>:
You could work around the problem by having a small script that
reverts changes to those files (provided you don't usually edit them,
of course, in which case this would eventually bite you). Something
along the lines of
$ git checkout -- $(git ls-files '*.someExt')
might do the trick.
(It doesn't seem like checkout accepts --stdin or -z parameters, so
this isn't as robust as it could be.)
Just throwing an idea out there -
If the locally-changed files need to be kept around (which often
happens when the changes reflect the local environment settings),
perhaps you could create a branch called "config", and keep the
changes there. The workflow would be somewhat along these lines:
# stay on the master branch
1) $ git checkout config -- foo && git reset HEAD -- foo
# work on master. Whenever you need to commit regular workfiles...
2) $ git checkout -- foo
# do the usual git status and commit stuff. Go to 1) when you are done.
Some wrapper scripts might be in the order if there are more than one
file like this. Also if one of these files gets changed, they need to
be committed in 'config'.
Cheers.
--
Jing Xue
-
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
