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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html