From: Jon Forrest <nobozo@gmail.com>
Date: Fri, 23 Sep 2011 13:45:27 GMT
Subject: Re: What's The Right Way to Do This?
Message-ID: <4E7C8D77.4020707@gmail.com>
In-Reply-To: <4E7C27A0.9030900@diamand.org>

On 9/22/2011 11:30 PM, Luke Diamand wrote:

> Someone will be along soon to correct me, but I think you should have
> rebased against the master branch rather than merged. Something like:
>
> % git rebase origin
>
> That way your changes would remain appended to the tip of the master
> branch. That will in general make your life much easier for all sorts of
> reasons.

In considering this, I'm having trouble understanding when to do a merge
as opposed to a rebase. Let's say that other people weren't putting
changed back in the remote master. So, my changes would always be at the
tip. Is that when I should merge? If so, then this suggest that knowing
what to do depends on knowing what other people are doing. But, doesn't
this go against the philosophy of a distributed SCM?

> At a guess, git revert created a commit that undid your _merge_, rather
> than your commit. The merge included all those other changes....
>
> It's a good idea to take a look at what a commit does before pushing it
> - "git show HEAD" is your friend.

IIRC, I did this and I saw the collection of the changes I had
made plus what other people had made. I didn't know how to revert
only my changes.

> Use git rebase (*) to keep your changes nicely arranged at the top of
> the main branch.

Thanks. I'll study up on this.

> I think you could award yourself a nice cup of tea after an experience
> like that though, having been on both sides of it, I can imagine you
> need it :-P

It certainly wasn't my finest hour!

Jon