On Mon, Jun 8, 2009 at 11:22 AM, Johan Herland <johan@xxxxxxxxxxx> wrote: > > Git, instead encourages you to commit your changes _first_ > (aka. "commit-before-merge"), so that your changes are not necessarily > affected by the updated changes from the server. The problem I have with this is that it's a lot of extra work to commit, pull (which will create a merge commit), then back out the merge commit git pull did, back out my local commit, then re-apply my local changes. I typically always have some modified files in my tree for little things I may never want to commit. I'll tweak some build Makefile build setting (e.g. enable extra logging, some debug printfs, etc.). These changes are very transient. We tend to pull in changes several times a day as people change stuff. It looks like I can use git stash to help here. If I do 'git stash && git pull && git stash pop', it seemed to work in a simple example. If I had no changes, I'd need to be careful to not try to do a git stash pop since it would haven't stashed anything. Is this something that would be pretty easy to add to git pull (or I guess really to git merge since pull is just fetch+merge)? Maybe something like a 'git pull --rebase-local'? If I wanted to add something like this, should I just start by looking at git stash and see how it does it and try to integrate support for that into git merge (and make sure git pull will pass that option through to git merge)? Conceptually, it seems easy, but I don't know how hard it would be to get it into the code. -- 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