Thanks for the clarification, and thanks all on the thread for
explaining things to me.
It appears that fetching with my local changes is not a problem. For
going the other way, you suggest:
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^".
I get the idea of floating "that" change to the top and using "push
HEAD^", though I've never tried --interactive so I'll have to play
around with that on a backup first.
I think if those changes are not committed, it won't be an issue.
So, my plan at this point is to "stash" my Local Change, and then apply
it. Then just keep it out of the index. If I do get a conflict, I can
re-apply my change from the stashed copy.
Ordinarily, I'll all about working on a feature on a branch, exposing a
"task based" system to other developers. But, this particular change is
not isolated, and I'm adding parameter to functions and such (I'm
changing the way configuration works and making more things
configurable) all over the place. I want to push stable work frequently
so other changes don't get too far away making a merge nightmare.
<rant>
Last time, I was careful to publish stable code frequently to the
official "dev" branch, but when another major feature was finished, they
just declared that branch to be the new main-line official branch.
</rant>
-----Original Message-----
From: Brian Gernhardt [mailto:benji@xxxxxxxxxxxxxxxxxx]
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
