On Feb 25, 2009, at 1:02 PM, John Dlugosz wrote:
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,
As Junio and Linus have pointed out, most pulls will ignore local
changes,
so this is likely overkill unless your changes are in commonly changed
files.
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.
You can set branch.master.rebase with
git config branch.master.rebase true
It actually works the other way. Your changes will be rebased on top of
the work from other developers.
A--B--E--F origin/master
\
C--D master
will become
A--B--E--F origin/master
\
C'--D' master
I share most of my changes using format-patch and e-mail instead of
pushes, so I just don't generate patches for my unimportant changes.
For pushing, I'd suggest either working on new features in a different
branch ("topic" and "local" for example), or using "rebase -i" to move
your local changes to the top and using "push HEAD^".
~~ Brian
--
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
