On Monday 08 June 2009, skillzero@xxxxxxxxx wrote: > If I have some local changes to a file that I don't want to commit > (e.g. temp debug changes like printf's) and I see somebody else has > pushed some changes to that file, how do I merge their changes to the > file while trying to preserve my local changes (and conflicting if > it's not possible)? > > After a git fetch, I tried 'git checkout --merge origin/master <path > to my locally modified file>', but that just overwrote my local > changes. > > I'm converting people from CVS to git and this is a common thing > people do with CVS. They have some local changes and see that the > server has some other changes so they do 'cvs up' and it tries to > merge changes from the server into the locally modified file. The > local changes are often things that will never be committed. I know > git tries to avoid things you can't undo, but like a 'git checkout > <file>' that can't be undone, is there a way to say "merge what you > can and generate conflict markers for things you can't?". > > I think what I want to do is the equivalent of rebasing for local > modified files rather than committed files. Being a CVS convert myself, I know this may be difficult to grasp when coming from CVS. Here's the deal: In the scenario you describe above, CVS forces you to merge your local modifications with the updates from the server. Thus, if/when you commit your changes, they will no longer be your changes only, but they will also contain whatever you did to resolve the conflicts. (This is also know as "merge-before-commit".) 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. By committing your changes first, you can choose at a later date whether to _merge_ your changes into the updates from the server (in a separate merge commit), or whether to _rebase_ your changes on top of the updates from the server (as if you made your changes after the update, and not before the update). In this scenario, since you have not published your changes, it makes sense to rebase them on top of the updates from the server. In other words, what you should do is first "git commit" your changes, and then "git fetch" and "git rebase origin/master". (You can also use "git pull --rebase" instead of the last two commands.) Now, since you probably don't want to push your changes (debug printfs etc.), you should probably put them on a separate branch, so that they are not automatically part of your next "git push". If you have already committed them to you local "master" branch, you can do the following: git checkout -b debug # Create and switch to a new branch "debug" git branch -f master HEAD^ # Reset "master" to the previous commit Your "master" is now back "in sync" with the server, and you have a debug branch which contains your debug printfs. Now, when you make further changes, you can choose whether to put them on "master" or "debug". With a default push configuration, "git push" will now push "master", but not "debug", so your debug printfs will stay in your local repo. Note that if you still need the debug printfs after there are more commits on "master", you will have to git checkout debug git rebase master to put your debug printfs back on top of the "master" branch. BTW, I find it very helpful to use gitk to visualize the commit history before and after each of these commands, so that I get a "natural" feel for how each command operates on the commit graph. Have fun! :) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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