9 ms·

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

Sir_Cmpwn 7y ago
I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."
- mixmastamyk 7y ago
  Most shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?
  - Sir_Cmpwn 7y ago
    So you're saying we shouldn't argue for the adoption of good software design practices? There are a lot of software teams that do care, you know.
    - mixmastamyk 7y ago
      But this isn't that. It's one step removed. Maybe if the UI gets better. Even then an uphill battle.
- fulafel 7y ago
  PRs are a good unit of changes for examining meaningful units of changes. No reason to lose info about how the sausage was actually made, it is also a valuable record
- gshulegaard 7y ago
  My biggest issue with that argument though is what constitutes "good" is subjective. For me a good commit history is one that faithfully chronicles what happened. With this in mind, acceptable curation of the history for me is squashing or separating commits and neither of these require rebase. But I wouldn't object if a colleague chose to use rebase to accomplish this. I would, however, object to reordering commits or rebasing since this alters the chronicle. Which I guess leaves me with my opinion on rebase: You can, but you don't need to. If you are going to, be sure you understand what you are doing and don't alter the chronicle.
nothrabannosir 7y ago
Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking is lovely between branches , but if a commit introduced a bug and another fixes it, now you always have to cherry pick them together. Easier to fix it and keep them atomic. A clean git history is not a vanity project. It can be used as a tool in further code building.
- mixmastamyk 7y ago
  Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time. As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure. This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average developers paid for delivering business value.
  - zemo 7y ago
    You're talking about a UI failure but you're not actually considering the entire experience. Reading the history of the project is a big part of the experience, especially for people in team lead roles. How much of your experience is writing code versus reading code? A merge-oriented workflow often results in a history that is deeply confusing to read. The only part of the experience that you're considering is the authorship of commits, not the utilization of the project's history. I've found a rebase-oriented workflow to result in a significantly more usable repository inasmuch as the history is significantly easier to understand.
    - mixmastamyk 7y ago
      History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.
rich-tea 7y ago
What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.
- jaequery 7y ago
  can't you do similar by tagging? and then later just diffing against them?
  - rich-tea 7y ago
    I'm not talking about squashing the feature branch. I'm talking about squashing all of master down to one commit (initial commit). If you don't take care of your history, my question is why do you keep it at all?
- rgoulter 7y ago
  While I like the idea of rearranging commits to convey a nice (but "not how it originally happened") development sequence, I think in practice this matters less than (say) good commit messages, or the difference between merging and rebasing. (--fixup type commits aside). Practical benefits from not squashing history: - Can bisect to find bug introduction. - Can annotate/praise/blame to find who/when some change was made. - Adam Tornhill's "Code as a Crime Scene" argues that it'd be beneficial to consume VCS history to provide health metrics on the codebase. (e.g. use VCS to check which sources have many contributors (thus potentially high defects), or check for "lost knowledge" from developers who have left). - Can build/run an older version of the software. But is there really a big advantage from putting time into maintaining a sequence of commits? EDIT: Ah, I see another comment point out that "maintaining a nice history" tends to mean fixing very borked commits. That makes sense. :-)
  - rich-tea 7y ago
    All of these advantages don't make sense if half your commits are broken versions of the software. Rebasing helps ensure that each commit is valid. That's important for the reasons you mention. Having a log of what you actually did is not important.
umvi 7y ago
Do you use feature branches? Interactive rebases are super nice for cleaning up feature branches before submitting a PR because no one wants to see your broken, non-atomic commits that have swear words in the commit message. If you submit a PR to my project on GitHub and it consists of 20+ broken, non-atomic commits leading up to the final one, I'm going to ask you to clean them up and squash into one.

I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."

mixmastamyk 7y ago
Most shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?
- Sir_Cmpwn 7y ago
  So you're saying we shouldn't argue for the adoption of good software design practices? There are a lot of software teams that do care, you know.
  - mixmastamyk 7y ago
    But this isn't that. It's one step removed. Maybe if the UI gets better. Even then an uphill battle.
fulafel 7y ago
PRs are a good unit of changes for examining meaningful units of changes. No reason to lose info about how the sausage was actually made, it is also a valuable record
gshulegaard 7y ago
My biggest issue with that argument though is what constitutes "good" is subjective. For me a good commit history is one that faithfully chronicles what happened. With this in mind, acceptable curation of the history for me is squashing or separating commits and neither of these require rebase. But I wouldn't object if a colleague chose to use rebase to accomplish this. I would, however, object to reordering commits or rebasing since this alters the chronicle. Which I guess leaves me with my opinion on rebase: You can, but you don't need to. If you are going to, be sure you understand what you are doing and don't alter the chronicle.

nothrabannosir 7y ago

Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking is lovely between branches , but if a commit introduced a bug and another fixes it, now you always have to cherry pick them together. Easier to fix it and keep them atomic. A clean git history is not a vanity project. It can be used as a tool in further code building.

mixmastamyk 7y ago
Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time. As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure. This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average developers paid for delivering business value.
- zemo 7y ago
  You're talking about a UI failure but you're not actually considering the entire experience. Reading the history of the project is a big part of the experience, especially for people in team lead roles. How much of your experience is writing code versus reading code? A merge-oriented workflow often results in a history that is deeply confusing to read. The only part of the experience that you're considering is the authorship of commits, not the utilization of the project's history. I've found a rebase-oriented workflow to result in a significantly more usable repository inasmuch as the history is significantly easier to understand.
  - mixmastamyk 7y ago
    History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.

rich-tea 7y ago

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.

jaequery 7y ago
can't you do similar by tagging? and then later just diffing against them?
- rich-tea 7y ago
  I'm not talking about squashing the feature branch. I'm talking about squashing all of master down to one commit (initial commit). If you don't take care of your history, my question is why do you keep it at all?
rgoulter 7y ago
While I like the idea of rearranging commits to convey a nice (but "not how it originally happened") development sequence, I think in practice this matters less than (say) good commit messages, or the difference between merging and rebasing. (--fixup type commits aside). Practical benefits from not squashing history: - Can bisect to find bug introduction. - Can annotate/praise/blame to find who/when some change was made. - Adam Tornhill's "Code as a Crime Scene" argues that it'd be beneficial to consume VCS history to provide health metrics on the codebase. (e.g. use VCS to check which sources have many contributors (thus potentially high defects), or check for "lost knowledge" from developers who have left). - Can build/run an older version of the software. But is there really a big advantage from putting time into maintaining a sequence of commits? EDIT: Ah, I see another comment point out that "maintaining a nice history" tends to mean fixing very borked commits. That makes sense. :-)
- rich-tea 7y ago
  All of these advantages don't make sense if half your commits are broken versions of the software. Rebasing helps ensure that each commit is valid. That's important for the reasons you mention. Having a log of what you actually did is not important.

umvi 7y ago

Do you use feature branches? Interactive rebases are super nice for cleaning up feature branches before submitting a PR because no one wants to see your broken, non-atomic commits that have swear words in the commit message. If you submit a PR to my project on GitHub and it consists of 20+ broken, non-atomic commits leading up to the final one, I'm going to ask you to clean them up and squash into one.