4 ms·

This article has been written a million times already. It's another holy war. Vim, spaces, rebase. The sad part is that IMO merge people are on that side becau

by hashkb 10y ago

This article has been written a million times already. It's another holy war. Vim, spaces, rebase. The sad part is that IMO merge people are on that side because they are afraid of rebase or don't understand it.

wwalser 10y ago
Teaching anything has to be done many times. Depending on the audience the degree of specificity that one goes into while teaching is variable. I personally read this as an attempt to teach and that teaching to be directed at newcomers to git. Nothing more. 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.
elsurudo 10y ago
> The sad part is that IMO merge people are on that side because they are afraid of rebase or don't understand it. 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.
- hashkb 10y ago
  With all respect, I disagree. For me rebase has identical difficulty but more flexibility. You could call that "much more complex" and I can call it "just as easy but way more powerful" and we'd both be right, I suppose. 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/
tapan_k 10y ago
Why is this downvoted? (serious question) Where can I find the "code of conduct" for HN?
- dahart 10y ago
  One can only speculate on why either downvotes or upvotes occur, but it's fairly safe to assume someone disagreed with something said in the comment. 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/newsfaq.html https://news.ycombinator.com/newsguidelines.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. ;)
  - tapan_k 10y ago
    Thank you for the links to guidelines. This helps.
  - hashkb 10y ago
    I read it. I thought it was a blog post and not part of their guide; so I can take back the timeliness/repetitive part of my complaint. 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.
    - dahart 10y ago
      Then I'm another example in a long line of examples that demonstrate that speculation doesn't always produce high quality results. 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.

by hashkb 10y ago

wwalser 10y ago

Teaching anything has to be done many times. Depending on the audience the degree of specificity that one goes into while teaching is variable. I personally read this as an attempt to teach and that teaching to be directed at newcomers to git. Nothing more. 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.

elsurudo 10y ago

> The sad part is that IMO merge people are on that side because they are afraid of rebase or don't understand it. 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.

hashkb 10y ago
With all respect, I disagree. For me rebase has identical difficulty but more flexibility. You could call that "much more complex" and I can call it "just as easy but way more powerful" and we'd both be right, I suppose. 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/

tapan_k 10y ago

Why is this downvoted? (serious question) Where can I find the "code of conduct" for HN?

dahart 10y ago
One can only speculate on why either downvotes or upvotes occur, but it's fairly safe to assume someone disagreed with something said in the comment. 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/newsfaq.html https://news.ycombinator.com/newsguidelines.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. ;)
- tapan_k 10y ago
  Thank you for the links to guidelines. This helps.
- hashkb 10y ago
  I read it. I thought it was a blog post and not part of their guide; so I can take back the timeliness/repetitive part of my complaint. 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.
  - dahart 10y ago
    Then I'm another example in a long line of examples that demonstrate that speculation doesn't always produce high quality results. 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.