Hm... I think this post is rather myopic and very specific for the author's workflow.
> "This bug started happening on Tuesday last week" [...] If you aren't aware of this and you start running your "git bisect" using your "good" base as the last commit made on Monday last week [...]
Well, or you could find the first commit on Tuesday last week and start with its parent. Or, better yet, have "releases" tagged or at least have a log of deploys (timestamps, commits); what if I developed something on Sunday and pushed it to production on Tuesday?
> You only get the plethora of merges if you're using git wrong.
I've seen it in real-world codebases. Some people just don't know how to use git very well (either can't understand it, or don't try to), and produce ugly history. I agree that for "noobs" it's better to merge than to rebase (less opportunities for failure), but good developers should know there's a place for both `rebase` and `merge`.
> And you do have a problem, because not only are you writing crap code, but you're committing it as well!
Well, one idea of git is to "commit early, commit often". It's much better to commit bugs and then commit fixes as well than to not commit and loose a bunch of code (due to a mistake or hardware failure).
I use rebase often. I should probably commit more often. Everyone has their own way, and we can all learn other ways and improve our work and life. But getting all angry and upset because someone uses rebase more often than you is an ineffective way to learn.
> "This bug started happening on Tuesday last week" [...] If you aren't aware of this and you start running your "git bisect" using your "good" base as the last commit made on Monday last week [...]
Well, or you could find the first commit on Tuesday last week and start with its parent. Or, better yet, have "releases" tagged or at least have a log of deploys (timestamps, commits); what if I developed something on Sunday and pushed it to production on Tuesday?
> You only get the plethora of merges if you're using git wrong.
I've seen it in real-world codebases. Some people just don't know how to use git very well (either can't understand it, or don't try to), and produce ugly history. I agree that for "noobs" it's better to merge than to rebase (less opportunities for failure), but good developers should know there's a place for both `rebase` and `merge`.
> And you do have a problem, because not only are you writing crap code, but you're committing it as well!
Well, one idea of git is to "commit early, commit often". It's much better to commit bugs and then commit fixes as well than to not commit and loose a bunch of code (due to a mistake or hardware failure).
I use rebase often. I should probably commit more often. Everyone has their own way, and we can all learn other ways and improve our work and life. But getting all angry and upset because someone uses rebase more often than you is an ineffective way to learn.