Re: Files different for me
- From
Brian Gernhardt <benji@silverinsanity.com>
- Date
- Feb 25, 2009, 18:38 UTC
- Message-ID
- <013B8F55-FBCC-4D3B-9EA4-13C05FFE986B@silverinsanity.com>
- In-Reply-To
- <450196A1AAAE4B42A00A8B27A59278E709E0486D@EXCHANGE.trad.tradestation.com>
On Feb 25, 2009, at 1:02 PM, John Dlugosz wrote:
Show 7 quoted lines
>> 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.
Show 10 quoted lines
> 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 masterwill become
A--B--E--F origin/master
\
C'--D' masterI 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