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