I used to be under the impression that I had to be extra formal and maintain a proper etiquette when writing git commit messages. After all, my work flow mostly consists of hacking on a branch, merging all the commits into master and the pushing upstream.

Whenever I felt like committing I used to think: "Well, this doesn't really mark a milestone in anything. Why would it make sense to have it on the main branch as a commit for the future generations to see?"

Turns out I was doing it all wrong because I had yet to meet git cherry-pick and didn't know you could "mash" commits together.

So suppose you start working on my_working_branch.

* 6390118 (master) third commit  kirbuchi, 2 minutes ago
* 40a6dfc second commit  kirbuchi, 3 minutes ago
* 03b732e (HEAD, my_working_branch) first commit  kirbuchi, 4 minutes ago

After a harsh battle with the new feature you're trying to implement, your new branch won't probably look so pretty. As a matter of fact, depending on your temper or what kind of day you're having, it may look something like this, if you don't hold back:

* e2124ed (HEAD, my_working_branch) work you piece of shit  kirbuchi, 30 seconds ago
* 371d5c0 oh god, why?  kirbuchi, 79 seconds ago
* 60d176c now it's hopefully ok  kirbuchi, 1 minute ago
* c8c3ce3 another change  kirbuchi, 2 minutes ago
* f7fd2b5 some tweak  kirbuchi, 3 minutes ago
| * 6390118 (master) third commit  kirbuchi, 5 minutes ago
| * 40a6dfc second commit  kirbuchi, 6 minutes ago
|/  
* 03b732e first commit  kirbuchi, 7 minutes ago

Of course you don't want your coworkers to stop thinking you're a nice guy so you may do the following.

git checkout master
git cherry-pick -n ..my_working_branch

The -n options tells git not to merge all the commits on top of you current branch but instead to have their changes applied on top of you working tree. Then you can commit with a more appropriate message.

git commit -m "Implemented new feature X"

And have everything look nice and presentable:

* 83449fa (HEAD, master) Implemented new feature X  kirbuchi, 10 minutes ago
* 6390118 third commit  kirbuchi, 13 minutes ago
* 40a6dfc second commit  kirbuchi, 14 minutes ago
* 03b732e first commit  kirbuchi, 15 minutes ago

Having this in mind, I now see a commit sort of like a save on one of those old console emulators where you could save and load your progress immediately if you die or screw up.

Of course I still believe proper etiquette must be maintained when working with others and I don't want to end up on this site or getting yelled at by famous geeks.

Today I learned the hard way about pip's --upgrade default behavior.

I wanted to upgrade a package and ended upgrading all it's dependencies, thus breaking my web app and wasting time hunting down the cause of the problem.

As clearly stated in the docs, the default behavior is to do a recursive installation, meaning upgrading every dependency to its latest available version even if already satisfied.

So I guess the title isn't really fair since this was clearly a product of me not RTFMing. I hope this works both as a reminder and a warning to be more careful in the future.

On the bright side, I understood why it's better to use --no-deps to not only prevent this but to ensure the exact stated packages will be installed when working with a requirements.txt file.