Dumb question about git

[Jonathan M Davis]

On Thursday, March 01, 2012 09:17:18 H. S. Teoh 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.

If you make changes in a branch and want them on top of what's in master, then 
do

git-rebase master

in _the branch_ and then merge the branch into master. And if you're using 
github to do pull requests and the like, then don't merge into master all. 
Simply create the pull request from the branch. That way, master only ever 
gets updated when the main repository gets updated, and you always have a 
clean version which matches the main repository.

- Jonathan M Davis