Re:Git rebase in depth
by Sir_Cmpwn on Friday May 10, 2019 @10:54AM
(#19878336)
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."
[ Parent
| on HN ]
Re:Git rebase in depth
by gshulegaard on Friday May 10, 2019 @01:20PM
(#19879998)
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.
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
Re:Git rebase in depth
by mixmastamyk on Friday May 10, 2019 @11:55AM
(#19878962)
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?
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.
Re:Git rebase in depth
by mixmastamyk on Friday May 10, 2019 @12:22PM
(#19879274)
But this isn't that. It's one step removed. Maybe if the UI gets better. Even then an uphill battle.