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

From: Luke Diamand <luke@diamand.org>
Date: Sep 23, 2011, 06:30 UTC
Message-ID: <4E7C27A0.9030900@diamand.org>
In-Reply-To: <loom.20110923T064720-366@post.gmane.org>

On 23/09/11 05:48, Jon Forrest wrote:

Show 11 quoted lines

> 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.

Show 14 quoted lines

>
> 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.

Show 6 quoted lines

>
> 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.