Anyone reading something like this as a newcomer is free to go on to become an expert and for their own opinions and practices. For an experienced practitioner to read a "Tutorial" and deem it dogmatic because it doesn't adhere to their specific and experienced approach ignores the fact that the practitioner has the benefit of significant experience that a new learner does not.
Where can I find the "code of conduct" for HN?
The comment complains that the article provides nothing new and is feeding the rebase-vs-merge holy war. I would disagree with that, and it suggests to me the commenter didn't read the article. It's usually considered bad form to make comments on the headline without reading the article. This article in particular steers clear of all the holy war aspects of the rebase-vs-merge debate. I didn't downvote, but I speculate that's why it got downvoted.
In the HN FAQ is a link to guidelines: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsguidelines.html
One of which is "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." which is why you'll rarely see discussions about downvotes, and why usually speculation is all you get. ;)
I'm not complaining that it's feeding the holy war, just pointing out that it is one. My complaint is that we try to solve these issues with dogma, rather than expecting everyone to have a strong understanding of git, at which point all of the problems just sort of stop happening.
I've seen the holy war too, and I was impressed that this article took special care to stay completely out of it. I didn't see any dogma at all in this case, I saw helpful suggestions educating people about git and about when to make the call.
It isn't helpful in any discussion to just say "side X are afraid and stupid.", and especially not without a good justification.
No-one has (I believe) ever thought "Oh wow, I didn't realise I was being afraid and/or stupid, thanks for telling me. Now I'll change sides".
Not necessarily. I understand rebase, but it is often a much more complex operation than a marge, and for (often) little gain (cleaner log). So it's a tradeoff. When the team is small enough that log pollution isn't too much of an issue, it's not worth rebasing, IMO.
I use the rebase flow on my solo projects as well as advocate for it on large teams. Even (especially) when it's just me, having a tidy history saves me tons of time; especially when I'm prone to constant distraction by business-y things.
Edit: s/I/I'm/