Subject: Re: What's The Right Way to Do This?

From: Luke Diamand <[email-masked]>
Date: Fri, 23 Sep 2011 07:30:56 +0100

On 23/09/11 05:48, Jon Forrest wrote:
> I'm just now starting to use git for more than trivial things.
> Today I got myself in trouble. Here's what happened:
>
> 1) I pulled the master branch from the IT repository from our
> main git server.
>
> 2) I created a branch from this called "J" and started making changes.
>
> 3) Other people pulled master from IT and then pushed changes back.
>
> 4) I merged J with my master branch.

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.

>
> 5) I tried pushing my master back to origin but this failed with
> the usual message saying I first needed to pull from origin.
> So, I pulled and then pushed. This worked.
>
> 6) On another server where I was going to use my changes I pulled
> master from IT.
>
> 6) It turned out that my changes were incorrect. So, I tried to revert
> using various methods I found by googling "git revert". What happened
> was that when I tried to revert back to the commit before the one I
> made, the files I had modified *and* the files that apparently were
> modified by other people in #3 above were reverted. This wasn't what
> I wanted. I only wanted to revert the changes I had made.

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.

>
> With the help of someone more experienced than me we were able to get
> things back to normal but this experience left me wondering what I
> should have done in the first place. There's a chance I'm going to
> have to go through all this again as I try to fix the problem with
> my changes.

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

Use git show to check the sanity of what you're about to push upstream.

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

Regards!
Luke

(*) But note that rebasing can cause problems for people who are 
downstream of _you_. See the  git-rebase(1) man page.