Cassiano Leal

Or you can just use the official boot2docker installer: https://github.com/boot2docker/osx-installer

Will give you the docker client, boot2docker and everything you need to run docker on a Mac bundled in a simple mpkg installer! ;)

icanhazip.com responds a lot faster here. Same script-friendly format. :)

This is what I used in the past: https://github.com/mpasternacki/capistrano-offroad

@likeyn -- no apologies necessary, no hard feelings here.

I understand your points, and I think they're pretty valid. My own experience has led me to the path of advocating for rebase instead of pull/merge in most cases, but maybe that's just because of mine and my team's specific workflow.

The comments on this protip is a heavy indication that there's plenty of uses for both (all) approaches. I always hope that people will make decisions taking into account their own reality, instead of following protips or other advices blindly. Worst-case scenario, people will learn from their own mistakes. :)

@likeyn I see your point about using it blindly before you understand how git works and it's a valid one.

rebase is even more dangerous when people realise they can git push -f what they've rebased, and that's the main reason why I usually let (and even teach) people use git pull blindly when they're getting started.

I know, this might sound contradictory to the article, but I believe that whoever gets here is either someone who's already curious enough go deeper, or will be intrigued enough to start digging.

@likeyn -- Obviously, the article's intention was to call the attention to the inherent danger of using git pull blindly. I understand that many people feel very attached to their way of doing things, but that shouldn't hinder contextual and subjective evaluation.

If you understand what git pull does, and you know that that's what you want at that moment, by all means use it! The problem I see is that many people blindly use it when they should actually be rebasing their local commits instead of merging (or even doing something else altogether), leading to an incomprehensible spaghetti commit graph, that's neither true to everyone's intention, nor bisectable.

Also, a minor correction: not all "normal" commits (whatever this is supposed to mean) have two or more parents. Most have only one, and there's the first commit that has none. :)

Just for the sake of not confusing users who bump into this protip, ruby-local-exec has been deprecated in rbenv 4.0. More info here: https://github.com/sstephenson/rbenv/wiki/ruby-local-exec

@manuite: I like git flow. I don't think that it's the best for everyone or every project, but it's still a great reference.

I personally use flow or some variation of it in most of my projects, and it helps to keep things organised.

This post seems to be causing a lot of confusion, so let me make this clear: I am not, in any way, advocating that you should always use rebase instead of merge. If you thought that, then please re-read this tip's title and you might get the clue.

By using this proposed approach, you will never change any history that's already been publicised. You're rebasing your local changes on top of whatever is in the repo. The whole point of this tip is for you not to publicise messed up history, or as I like to call it, a spaghetti.

A few clarifications that should have been obvious by reading the tip, but it seems I'm failing a bit in communicating. :)

1 - I'm talking about work in one branch, not between branches.

2 - If you fetch before you rebase the branch onto its own remote branch, you won't ever alter whatever history is already in the repo.

@jwebcat: Thanks for the tip, I'm updating mine to reference yours as well.