<p><br>
On Mar 1, 2012 12:15 PM, "H. S. Teoh" <<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>> wrote:<br>
><br>
> On Thu, Mar 01, 2012 at 10:22:33AM -0500, Kevin Cox wrote:<br>
> > When people say git encourages rewriting history.  Don't listen.  Once<br>
> > you have pushed your changes to the world they are immutable.  This is<br>
> > because git uses cryptography internally and changing the history<br>
> > messes everything up.  If you haven't pushed you can change all of<br>
> > your history and it will all be fine.  But if someone else (github)<br>
> > has the old hisory bad things happen.  If you are sure nobody has<br>
> > pulled from github you can use --force when pushing (I think).  It<br>
> > will work no matter what but you will piss off people if they have<br>
> > pulled from you.  Please note that this kind of history modifying is<br>
> > considered bad practice.<br>
> [...]<br>
><br>
> OK, so what's the right way to do it then? I have some changes in a<br>
> branch, but master has been updated since, so I want to merge in the<br>
> latest updates so that the branch changes are compatible with the latest<br>
> code. If I just pull from master, then my changes get buried underneath<br>
> the newest changes.<br>
><br>
> I guess I still don't quite understand how things are supposed to work<br>
> in situations like this.<br>
><br>
><br>
> T<br>
><br>
> --<br>
> Music critic: "That's an imitation fugue!"<br></p>
<p>This time I would just --force.  In the future the idea is to only push changes once you are happy with them.</p>
<p>What I would do next time is:<br>
- work<br>
- commit<br>
- work<br>
- commit<br>
- pull<br>
- rebase (make what you have done look pretty)<br>
- push</p>