Dealing with rejection in git, resetting your master to theirs and starting over
Posted by Justin on July 3rd, 2010 filed in Just A Programmer
You haven’t really started using git until you’ve gotten your first patch rejected. Due to the nature of git, merging is easier, but rejection is harder. Well if I was using branches it wouldn’t be that big of a deal, but thats besides the point.
You see I developed a love/hate relationship with a wonderful NoSQL database called MongoDB, that led me to contribute patches to it. I loved it because its awesome for a few specific tasks I need to do, but found its windows support a little lacking. It ran and performed great in windows, and even ran as a proper NT Service. However, it needed a little spit and polish. It was also a great excuse to do some hardcore windows system programming, and logging calls. Ask any sysadmin that ever had to support a program I wrote, I love verbose debug logs.
So every once in a while one of my pull requests got rejected. The first few times it took me a while to deal with it. I don’t mean it took me a while emotionally to deal with the fact that my code is anything but perfect. I mean that it took me a while to reset my git repo with the main 10gen repo. Sure I could have deleted it and started over, but I wanted to learn how to use git properly.
So in the end I asked on the Long Island Linux User Group’s mailing list and got a helpful reply from Mark Drago. I actually linked to my reply to his reply, since I make a correction. So without further ado, here what I did.
Ok a little more ado. My repo is refereed to as origin in the config and 10gen’s is referred to as 10gen. I wanted to save my master branch’s current state to a newly named branch delete my master and pull from 10gen’s master. In the end my problem was I never did a git fetch. The final sequence of commands I did type was:</ado>
- git checkout master
- git checkout -b oldmaster
- git branch -d master
- git fetch 10gen #Needed to get the list of branches in master.
- git checkout remotes/10gen/master
- git checkout -b master
- git push -f origin master
And that was it. I was free to continue to write code.
6 Responses to “Dealing with rejection in git, resetting your master to theirs and starting over”
Leave a Comment
You must be logged in to post a comment.
July 3rd, 2010 at 10:49 pm
Subversion > git
July 3rd, 2010 at 10:49 pm
I’m also not really sure why you are so afraid of branches.
If it takes you more than a day to write a piece of code… it should be in a branch.
July 3rd, 2010 at 10:54 pm
I’m not afraid of branches, just having trouble getting into the habit of branch per feature.
I’ve been doing a branch after release at my current job with svn, and gotten one of my coworkers to consider it.
I do need to learn to branch before the fact, especially on my Saturday one man mongo hackathons. If I start the day with a 5-10 item todo list I should make 5-10 branches, cherry pick my commits back to my master and send a pull request.
July 3rd, 2010 at 11:02 pm
It’s a good habit to branch before the fact, but you can base your branch off your current working copy with svn.
I often find myself doing that at work when I take on a ticket that I think will be easy, then when 5:30 rolls around I just check my changes into a branch and resume the next day.
July 3rd, 2010 at 11:09 pm
Oh… and microsoft gave a name to what I described above. They call it “shelving.”
Whatever… its a branch off based on workspace.
They can call it magical for all I care. I’ve been doing it for years.
July 3rd, 2010 at 11:13 pm
This is a different scenario than branching off the working set.
1) Assign myself a work item (contributing to an OSS project in my free time I get to pick)
2) Code/Compile/Test/Retest/Whatever
3) Commit working code
4) Push to my github branch
5) Send a pull request
6) Get a rejection (usually with a try again later)
So what I really need is a branch strategy that involves having a branch of mine thats always a pristine copy of their master, so I can rename my master with impunity.