Hacker News new | ask | show | jobs
by erso 4801 days ago
Except this idea of the context in which you wrote the code doesn't actually matter to anyone.

More likely you're going to piss off everyone that has to deal with your merge strategy because your commits that couldn't be merged into master are broken, having been fixed as part of the merge commit(s).

Such commits:

* Aren't able to be bisected (they're broken, remember?)

* Aren't able to be blamed (the collective merge commits and the actual commits have to be considered at the same time)

* Aren't able to be rebased later when you decide, actually, this merging shit is ridiculous (the -p option to rebase is dangerous and doesn't always work the way you think it will)

* Aren't able to be traversed cleanly in a log because they're probably split up with merges of master into your branch all over, because hey, you wanted to stay up to date.

* Basically aren't understandable by anyone, including you.

Being that it's not 2011 anymore (sorry, what?), you should learn how to use Git properly, understand what effects your workflow have both to you and to those that read your code (including you!), and those that choose to use Git's tools.

I once had a situation on a client project while at Pivotal where a guy had been working on a branch for 2 months, continuously merging master into his branch. It was a shitshow. He had 45 commits of his own plus 10-15 merge commits from origin/master. Doing a git log of that nonsense was basically impossible to read, impossible to code review (the client's process at the time), and when merged back into master would have been the most crazy ass log --graph I can imagine (because everyone else was doing similar nonsense). We're talking a 10-pair dev team all merging origin/master into their local master. The log was unreadable, unusable, not to be understood by anyone.

Luckily I was able to remove all the merge commits via the 2-argument form of rebase --onto, (http://krishicks.com/blog/2012/05/28/git-rebase-onto/) which then gave him the freedom to squash, reorder, fixup, and split his commits as he felt necessary to maintain his and everyone else's sanity. In the end he filtered it down to something like 20 very clean, green commits that could be reviewed by another person and understood, and rebased on top of origin/master.