3 ms·

To anticipate some misunderstandings, I posted this in the light of Jeff Kreeftmeijer's latest post, "The magical (and not harmful) rebase"[1][2]. I had never r

To anticipate some misunderstandings, I posted this in the light of Jeff Kreeftmeijer's latest post, "The magical (and not harmful) rebase"[1][2]. I had never read the full original "Rebase Considered Harmful" article, and after reading both posts, I'm not sure how I feel about rebase overall. Since I use Git, I'm curious to hear more from others. Some people worry about rebase (reasonably) in terms of messing up other people's repos, but that seems like a simpler problem. Just don't do it. (Everyone would agree you shouldn't mess with history that is already public.) I'm more curious about rebasing to produce a "clean" history. I'm not sure I like the idea of all history looking like a smooth, linear progression. (Let's set aside simple amends for typos and or leaving one file out of a commit. Those seem trivial and again not controversial.) If the point of rebase is to always smooth things out, I worry about the larger picture being lost. Anyhow, I wonder what more experienced people have to say. (Edited to make my concerns clearer.) [1] http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful-rebase/ http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful... [2] Discussion of [1] here on HN: http://news.ycombinator.com/item?id=1779481 http://news.ycombinator.com/item?id=1779481

madhouse 16y ago
I use rebase often: I develop on a feature branch, experiment there a lot, and before I push it, I rebase it to squash the thing into more managable and straightforward pieces. (I push my branches public when they're ready, and when I won't rebase them anymore) For example, there's this project where the test environment is on another system, and I hardly ever test locally. So when I break something, there's a good chance I won't notice that until the test runs. At that point, I make a small commit to fix it. I could push that all out, and merge the whole thing onto my master branch, but that would be a lot of useless clutter: development mixed with random fixes. I prefer my development line reasonably clean, so I rebase & squash things together before making them public. This doesn't mean that my whole feature development will be one big patch, no. But it will be a series of clean changes, as it should be. Easier for everyone to understand later. One line of development will look like a smooth, linear progression, but there can be many similar feature branches, which get merged to master at various points, and that line will not look all that linear. Smooth - hopefully, but not linear.

madhouse 16y ago

I use rebase often: I develop on a feature branch, experiment there a lot, and before I push it, I rebase it to squash the thing into more managable and straightforward pieces. (I push my branches public when they're ready, and when I won't rebase them anymore) For example, there's this project where the test environment is on another system, and I hardly ever test locally. So when I break something, there's a good chance I won't notice that until the test runs. At that point, I make a small commit to fix it. I could push that all out, and merge the whole thing onto my master branch, but that would be a lot of useless clutter: development mixed with random fixes. I prefer my development line reasonably clean, so I rebase & squash things together before making them public. This doesn't mean that my whole feature development will be one big patch, no. But it will be a series of clean changes, as it should be. Easier for everyone to understand later. One line of development will look like a smooth, linear progression, but there can be many similar feature branches, which get merged to master at various points, and that line will not look all that linear. Smooth - hopefully, but not linear.