> Generally when I keep changes like this, I make a commit called "Local > Changes" or similar and have branch.master.rebase set to true so that > my changes get rebased on top of origin when I pull. That sounds ideal. However, I don't understand the specific steps you mention. Looking in the help for git-config, branch.<name>.rebase When true, rebase the branch <name> on top of the fetched branch, instead of merging the default branch from the default remote when "git pull" is run. NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-rebase(1) for details). So, assuming you are working on the "master" branch, this will rebase the pulled content on top of the existing "master" rather than merging. If my local changes are committed to "master" first, then this will take all the commits from other developers that I don't already have in my local copy and apply them on top of my existing (including Local Changes). But since those will now be different commits, what happens next time? Ah, "...which introduce the same textual changes..." so that's covered in how rebase works. But this will have Local Changes present, and different commits (with the same textual changes) in my branch. So what happens when I "push"? Oldstuff--A--B--C remote \ LC--X--Y mine LC is "Local Changes", X and Y are changes I made, and A, B, C are changes from other developers. After a fetch, I have: Oldstuff--LC--X--Y--A'--B'--C' mine So what happens when I "push"? In any case, the whole point is that I don't want to publish LC. -- 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
