Conflict resolution on git


Git is just amazing. Learning command line git is one of the best thing that has happen to me. I’ve been lucky to work with some talented guys from bocoup, and I’ve gotten to know quite a bit about it lately and just wanted to document things that I do when I encounter that dreaded (well, not THAT bad) “We can’t automatically merge this pull request.” message.

Also if you have not seen this Cheat Sheet do yourself a favor and take a look.

So, pull request can’t be merged. It’s because what you worked on (likely your branch) have some conflicts with what you are trying to merge, likely origin/master. this stack overflow answer was useful in understanding what I am doing.

My instinct was to git pull. But that is a bad idea (Quick! git reset origin/your-working-branch --hard to get what you have pushed to github!). When you encounter “can’t merge” message, git’s help suggest this:

Step 1: From your project repository, bring in the changes and test.

git fetch origin
git checkout -b your-working-branch origin/your-working-branch
git merge master

fetch then merge is much better than pull. Pull does too much under the hood (as my co-worker Tim says “too much magic”). But still, chance is that you may end up with WAAAAY too many conflicts and therefore very hard to resolve them. Perhaps there is even better idea:

git fetch --all (You may not have to do –all, but I am paranoid and this is my feels safe blanket, if you know what I mean. It’ll ensure you have the latest remotes.)
then git rebase origin/master

Ah, rebase. I had sort of hard time understanding concept of rebase, but perhaps git’s message explained it to me the best. It says “First, rewinding head to replay your work on top of it…” All your commits are “replayed” after changes that are already in master. People used words like “flattening the history” when explaining rebase, which was confusing to me. but “replay your work on top” explanation worked best for me.

When you rebase, or “replay your work on top,” you resolve conflict one by one, as it encounters conflict.

You may get a message like this:

Applying: My commit 1.
Using index info to reconstruct a base tree...
M	source/js/file.js
M	source/js/folder/file.js
Falling back to patching base and 3-way merge...
Auto-merging source/js/folder/file.js
CONFLICT (content): Merge conflict in source/js/folder/file.js
Auto-merging source/js/file.js
CONFLICT (content): Merge conflict in source/js/file.js
Failed to merge in the changes.
Patch failed at 0002 My commit 1.

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Nice to have that –abort option. Unlike merge or pull, you can just forget about the whole thing. Continue till you are done.

But because rebase changes the history, you may get message like this.

Your branch and 'origin/your-working-branch' have diverged,
and have 95 and 2 different commits each, respectively.
 (use "git pull" to merge the remote branch into yours)

If you push force that message will go away
git push origin your-working-branch --force

$ git push origin your-working-branch -f
Counting objects: 51, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (13/13), 1.56 KiB | 0 bytes/s, done.
Total 13 (delta 8), reused 0 (delta 0)
 + 368da98...4266772 your-working-branch -> your-working-branch (forced update)

When you push force you’ll see the previous sha and the new one, so if you mess up and want to revert, simply reset hard on that previous sha and push force again
they look like previous_sha…new_sha

so in this case
git reset 368da98 --hard

In case of “Oh Crap, I made a spelling mistake and I just pushed that.”

You could git reset HEAD~1 -- soft to undo last commit and re do it, OR,
change the file, then git commit --amend
Either way, since you already “Pushed” you need to push –force to make it work.

If your working directory is dirty (meaning you have conflicts) and you don’t have any work you need to save:

# Cleans the working directory.
git reset HEAD –hard

# Reset the branch to the remote (in this case your-working-branch.
git reset origin/your-working-branch –hard

Continue reading…

Open Vis Conf 2014 was amazing! Love that conference.

Good people at Bocoup puts out this kick-butt conference in Boston every year. I am lucky to have participated in both of those years.


I only was able to go to one day of it this year, but it was very interesting and inspiring as last years. I whole heartedly agree with Mike Bostock’s sentiment of “design is hard” and it was helpful for me to see his breakdown of why. Neat to know about “Fitts’s Law.” NYTimes git tool called “Preview” which takes screenshot of git commits are pretty cool. Thoughts on explanatory graphic vs exploratory graphic. He says don’t be afraid to fail. Try bad idea deliberator to evaluate it. He says “Javascript” is “One True Language.” Sam Selikoff’s js framework talk was very interesting and I need/can’t wait to see the code. Kennedy Eliot of WaPo and Jen Christiansen’s talk was very close to my field. Print publication with online challenges. Finding “Narrative” in data. Story telling is important. All good design/presentation is a god story. ICanHaz.js sounds really interesting. I need to check it out. All the other talks, I have notes to go over, but was great. Nice to see all the folks too. Those are my people. Very inspiring.

I’ve been posting links that I liked at Posterous (RIP) and then my tumblr blog. Here are the week worth of Articles that I liked: Friday, May 9, 2014:

My talk from css meetup: Vector-based Responsive Web Design


I had a great time talking at April 22, 2014 Cascade Bos meetup. My talk was titled: Embedded web fonts, Icon fonts and SVG – Vector-based Responsive Web Design using CSS.

Coincidentally, the same day, Chris Coyer of CSS-Tricks have published a blog post titled: Inline SVG vs Icon Fonts [CAGEMATCH].

His conclusion is very similar to my conclusion but better!

If you can go IE 9+ / Android 3+, inline SVG is better at pretty much everything than icon fonts. If you need the deeper browser support, I feel like an inline SVG fallback would be too big of a pain to be worth it.

Definitely worth a read if you are interested in this topic.

Continue reading…