5 ms·

Nobody Cares About Your Git History

60 points by ingve 3y ago

8organicbits 3y ago
I think it helps to think about when people read the commit messages, and when commits impact workflows. Having tons of commits that are partially broken ("saving work") can make it harder to git bisect. I sometimes read commits to understand what's being worked on, again "saving work" is just noise. People on the Ops side, doing packaging, or deployment often care more about the commit messages. A good commit message can help them avoid looking at a diff, or understanding which commits need scrutiny.
- j4yav 3y ago
  I spent most of my career in ops, specifically packaging and deployment, and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie.
  - radiator 3y ago
    For some codebases, if you are lucky, you can trust commit messages from specific trustworthy people. Diffs might not lie, but they take much more space and time to read than 'git log --oneline'.
  - tivert 3y ago
    > ...and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie. That's a sentiment that's very easy to take too far, and shy people away from valuable commit message practices out of misplaced perfectionism. Diffs definitely can lie. Not about the way it is, but about the way it should be. Commit messages are insanely valuable, and often convey important information that's impossible or unreasonable to communicate in any other way (for instance, things like like intent and rationales). Diffs can say ABCD, commit messages can say CDEF. They all should be considered, together, but with a reasonable dose of skepticism, when you're figuring something out. Some things that are true (if you're system lives long enough): 1. There's a good chance your documentation wiki will get purged or severely corrupted in some migration before you lose your commit messages. 2. There's a good chance your ticket system will get purged or severely corrupted in some migration before you lose your commit messages.
- Vinnl 3y ago
  The challenge is that it's hard to see the value of good commits if you've never done a `git blame` or `git bisect`, but you can't really use those until you have good commits. A bit of a chicken and egg problem.
pnt12 3y ago
I've had to dig through the history of a 5 year old project - it was much nicer when the commits were focused, the PRs has nice descriptions and even better if associated with ticket. I will defend merge squash forever - low effort, good results. You do whatever you want in your feature branch, then merge squash. Everyone can do it. You want to split it in multiple commits? Then it probably should have been split in multiple PRs . I need to write an article about this so I can just link to it instead of writing the same comment evrytime :)
- progval 3y ago
  > You want to split it in multiple commits? Then it probably should have been split in multiple PRs . Sure, but GitHub/GitLab/Gitea don't let you write multiple PRs that depend on each other easily, like Phabricator/Gerrit/email do. Either it's a mess of branches merging into each other, multiple commits in the same PR, or wait for one PR to be merged before writing the next.
  - Varriount 3y ago
    If your PR is that big and has that many interconnected pieces, then it should probably be broken up and serially merged anyway. Otherwise it becomes a pain for the reviewers to read, and a pain to make any large changes to.
  - akoboldfrying 3y ago
    I think GitHub is pretty good here: If you make PR #1 from branch foo with target main, and PR #2 from branch bar (a descendant of foo) with target foo (that is, a "sub-PR" of #1), then if #1 gets merged first (into main), #2's target branch will auto-update to main, which is exactly what you want. If #2 gets merged first (into foo), then branch foo of course updates to include the commits in bar, which is again what you want. What behaviour were you hoping to see?
    - l72 3y ago
      Wow, I didn't realize github did this!
sureglymop 3y ago
What about a system where each "save" (ctrl+s) would be like a commit? But then only those saves which pass tests ensuring the application still runs get pushed.
- mrkeen 3y ago
  Kind of hard to put a failing test into the code.
nicexe 3y ago
I only skimmed the article. But my stance is, anyone that ever used cherry-pick or reverted multiple commits is impacted by clean git history. Unclean git history could make a simple 2 minute cherry-pick or revert task to a 30 mins+ job.
smcameron 3y ago
The article seems to present a dichotomy between what the author terms a "clean" git history, which he seems to think is a history where multiple commits are squashed into single commits that contain, I guess "one feature", and the unnamed "other" way of doing it, which the author doesn't really elaborate what exactly it is, but he appears to means willy nilly uncurated commits of whatever? To me, both ways he talks about are insane. With something like stgit[1], it is dead easy to maintain a stack of curated, small un-squashed git-bisectable commits, and your commit history looks like the work of a supernatural genius who knows exactly what he's doing and rarely makes mistakes, and if you have to port your patches (commits) across multiple variants of the same source (think linux drivers ported to multiple distro kernels) that's easy too. [1] https://stacked-git.github.io/ https://stacked-git.github.io/
flemhans 3y ago
It's weird, I'm at 20,000 commits and never used the history.
blagie 3y ago
This is a git design issue. History should be at the keystroke-by-keystroke level, which aggregates into small, focused commits, which aggregates into large merges. In other words, good written records have layers and organizations. A history book will have chapters, sections, sentences, and footnotes. A database might let me organize my corporate history by day and then by division, or flip it around, and organize by division and then by month. git his one linear history, which means it is navigable in one way, and you need to pick: - Complete record of what happened; - Small, cherry-pickable commits; - Clean list of when features got merged; or - Something else Don't make me pick!
- kenmacd 3y ago
  > git his one linear history > Don't make me pick! I'm not understanding what you mean... to me it doesn't. For example you can browse by 'chapters' by adding `--first-parent` to your `git log`. You have commits, which are paragraphs, then you have merges (ie chapters), and you can view from either view, or many others.
- tleb_ 3y ago
  I do not agree. Commits in my patch series have no link whatsoever with the chronology of my work. I wouldn't call it "Git history" as long as it is the branch I'm working on. It becomes history once it is merged inside a more persistent branch.
myaccountonhn 3y ago
I've been using commit-centric reviews and I've never encountered the issues he talked about. I try to make sure that each commit is complete (like a vertical) and use commit messages to provide context.
SeriousM 3y ago
Git blame is an essential part of my daily job to understand why a certain line of code was introduced or how it evolved over time. Hit history is important.
kenoyer130 3y ago
I don't understand why this causes so much confusion and conversation. If you are working with others then a force push is off the table. The only time you force push is to fix a catastrophic error. Forget it exists. When working locally please rebase LOCALLY and clean up your commits before pushing an MR. No one wants to see fix 1, fix 3, rollback etc. Plus team environments usually have strict commit templates linked to Jira tasks etc. Rebase -i is your friend. I think people for some reason struggle to understand their local git repo versus the actual shared git repo everyone is using.
seba_dos1 3y ago
I do. I do care about mine, because it helps me work, and I do care about yours when I contribute to your project, because it helps me work. Scrolling through the list of downsides, it seems like every single one of them should have "but only if you're doing it wrong" appended.
kutenai 3y ago
I use git rebase all of the time. We rebase all features onto develop. Develop is then merged --ff-only into stage/release, etc. Which is then merged --ff-only into main/master, and then tagged. I use squash less, as it can be helpful for blame of course, so rebase with minimal squash (like, squash that typo fix). The article makes it sound like a 'rebase' workflow is so complex, and time consuming. Poppycock. it's easy, and force pushing a branch cause practically zero issues for developers. If I have to rebase develop, for example, and then force push it, then remote users only have to do this: git checkout develop git reset --hard origin/develop Since a user would never have any local changes in develop, it would never be an issue. The "fanaticism" about and against rebasing is overblown in my opinion. Oh, and the "time wasted" dealing with merge issues.. same, exactly the same in fact. Granted, I don't go around rebasing everything all of the time, but a developer working on a feature just rebases to develop before they submit a PR. Sure, if there are multiple PR's then they also need a rebase merge, but since nobody would "continue" working on a feature once it is submitted, this isn't an issue. Oh, and IF they did, well, again, they can just pull develop and rebase their feature. Now, what I don't do is have multiple developers on a single feature branch. If my team was much larger, and that was a "normal process" then, it may well make rebasing more of an issue..
- orwin 3y ago
  Maybe you've only worked with average to good devs who communicate well, like I do now, but I guarantee that in our field, we have people who can at the same time be bad to average AND bad communicators (or worse, toxic liars). Luckily, now our worse communicator is also our most competent dev, but I've been in teams where learning basic git would be a month long challenge for half the people, and for half of those (two people, really, we were 9) communicating their difficulties, or worse, their mistakes was impossible.
smitty1e 3y ago
For now. The insistence that some future researcher may not care is myopic.
binary132 3y ago
Not true, I care. I read history to try to understand features and evolutions and bugs and people.

60 points by ingve 3y ago

I think it helps to think about when people read the commit messages, and when commits impact workflows. Having tons of commits that are partially broken ("saving work") can make it harder to git bisect. I sometimes read commits to understand what's being worked on, again "saving work" is just noise. People on the Ops side, doing packaging, or deployment often care more about the commit messages. A good commit message can help them avoid looking at a diff, or understanding which commits need scrutiny.

j4yav 3y ago
I spent most of my career in ops, specifically packaging and deployment, and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie.
- radiator 3y ago
  For some codebases, if you are lucky, you can trust commit messages from specific trustworthy people. Diffs might not lie, but they take much more space and time to read than 'git log --oneline'.
- tivert 3y ago
  > ...and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie. That's a sentiment that's very easy to take too far, and shy people away from valuable commit message practices out of misplaced perfectionism. Diffs definitely can lie. Not about the way it is, but about the way it should be. Commit messages are insanely valuable, and often convey important information that's impossible or unreasonable to communicate in any other way (for instance, things like like intent and rationales). Diffs can say ABCD, commit messages can say CDEF. They all should be considered, together, but with a reasonable dose of skepticism, when you're figuring something out. Some things that are true (if you're system lives long enough): 1. There's a good chance your documentation wiki will get purged or severely corrupted in some migration before you lose your commit messages. 2. There's a good chance your ticket system will get purged or severely corrupted in some migration before you lose your commit messages.
Vinnl 3y ago
The challenge is that it's hard to see the value of good commits if you've never done a `git blame` or `git bisect`, but you can't really use those until you have good commits. A bit of a chicken and egg problem.

pnt12 3y ago

I've had to dig through the history of a 5 year old project - it was much nicer when the commits were focused, the PRs has nice descriptions and even better if associated with ticket. I will defend merge squash forever - low effort, good results. You do whatever you want in your feature branch, then merge squash. Everyone can do it. You want to split it in multiple commits? Then it probably should have been split in multiple PRs . I need to write an article about this so I can just link to it instead of writing the same comment evrytime :)

progval 3y ago
> You want to split it in multiple commits? Then it probably should have been split in multiple PRs . Sure, but GitHub/GitLab/Gitea don't let you write multiple PRs that depend on each other easily, like Phabricator/Gerrit/email do. Either it's a mess of branches merging into each other, multiple commits in the same PR, or wait for one PR to be merged before writing the next.
- Varriount 3y ago
  If your PR is that big and has that many interconnected pieces, then it should probably be broken up and serially merged anyway. Otherwise it becomes a pain for the reviewers to read, and a pain to make any large changes to.
- akoboldfrying 3y ago
  I think GitHub is pretty good here: If you make PR #1 from branch foo with target main, and PR #2 from branch bar (a descendant of foo) with target foo (that is, a "sub-PR" of #1), then if #1 gets merged first (into main), #2's target branch will auto-update to main, which is exactly what you want. If #2 gets merged first (into foo), then branch foo of course updates to include the commits in bar, which is again what you want. What behaviour were you hoping to see?
  - l72 3y ago
    Wow, I didn't realize github did this!

sureglymop 3y ago

What about a system where each "save" (ctrl+s) would be like a commit? But then only those saves which pass tests ensuring the application still runs get pushed.

mrkeen 3y ago
Kind of hard to put a failing test into the code.

nicexe 3y ago

I only skimmed the article. But my stance is, anyone that ever used cherry-pick or reverted multiple commits is impacted by clean git history. Unclean git history could make a simple 2 minute cherry-pick or revert task to a 30 mins+ job.

smcameron 3y ago

The article seems to present a dichotomy between what the author terms a "clean" git history, which he seems to think is a history where multiple commits are squashed into single commits that contain, I guess "one feature", and the unnamed "other" way of doing it, which the author doesn't really elaborate what exactly it is, but he appears to means willy nilly uncurated commits of whatever? To me, both ways he talks about are insane. With something like stgit[1], it is dead easy to maintain a stack of curated, small un-squashed git-bisectable commits, and your commit history looks like the work of a supernatural genius who knows exactly what he's doing and rarely makes mistakes, and if you have to port your patches (commits) across multiple variants of the same source (think linux drivers ported to multiple distro kernels) that's easy too. [1] https://stacked-git.github.io/ https://stacked-git.github.io/

flemhans 3y ago

It's weird, I'm at 20,000 commits and never used the history.

blagie 3y ago

This is a git design issue. History should be at the keystroke-by-keystroke level, which aggregates into small, focused commits, which aggregates into large merges. In other words, good written records have layers and organizations. A history book will have chapters, sections, sentences, and footnotes. A database might let me organize my corporate history by day and then by division, or flip it around, and organize by division and then by month. git his one linear history, which means it is navigable in one way, and you need to pick: - Complete record of what happened; - Small, cherry-pickable commits; - Clean list of when features got merged; or - Something else Don't make me pick!

kenmacd 3y ago
> git his one linear history > Don't make me pick! I'm not understanding what you mean... to me it doesn't. For example you can browse by 'chapters' by adding `--first-parent` to your `git log`. You have commits, which are paragraphs, then you have merges (ie chapters), and you can view from either view, or many others.
tleb_ 3y ago
I do not agree. Commits in my patch series have no link whatsoever with the chronology of my work. I wouldn't call it "Git history" as long as it is the branch I'm working on. It becomes history once it is merged inside a more persistent branch.

myaccountonhn 3y ago

I've been using commit-centric reviews and I've never encountered the issues he talked about. I try to make sure that each commit is complete (like a vertical) and use commit messages to provide context.

SeriousM 3y ago

Git blame is an essential part of my daily job to understand why a certain line of code was introduced or how it evolved over time. Hit history is important.

kenoyer130 3y ago

I don't understand why this causes so much confusion and conversation. If you are working with others then a force push is off the table. The only time you force push is to fix a catastrophic error. Forget it exists. When working locally please rebase LOCALLY and clean up your commits before pushing an MR. No one wants to see fix 1, fix 3, rollback etc. Plus team environments usually have strict commit templates linked to Jira tasks etc. Rebase -i is your friend. I think people for some reason struggle to understand their local git repo versus the actual shared git repo everyone is using.

seba_dos1 3y ago

I do. I do care about mine, because it helps me work, and I do care about yours when I contribute to your project, because it helps me work. Scrolling through the list of downsides, it seems like every single one of them should have "but only if you're doing it wrong" appended.

kutenai 3y ago

I use git rebase all of the time. We rebase all features onto develop. Develop is then merged --ff-only into stage/release, etc. Which is then merged --ff-only into main/master, and then tagged. I use squash less, as it can be helpful for blame of course, so rebase with minimal squash (like, squash that typo fix). The article makes it sound like a 'rebase' workflow is so complex, and time consuming. Poppycock. it's easy, and force pushing a branch cause practically zero issues for developers. If I have to rebase develop, for example, and then force push it, then remote users only have to do this: git checkout develop git reset --hard origin/develop Since a user would never have any local changes in develop, it would never be an issue. The "fanaticism" about and against rebasing is overblown in my opinion. Oh, and the "time wasted" dealing with merge issues.. same, exactly the same in fact. Granted, I don't go around rebasing everything all of the time, but a developer working on a feature just rebases to develop before they submit a PR. Sure, if there are multiple PR's then they also need a rebase merge, but since nobody would "continue" working on a feature once it is submitted, this isn't an issue. Oh, and IF they did, well, again, they can just pull develop and rebase their feature. Now, what I don't do is have multiple developers on a single feature branch. If my team was much larger, and that was a "normal process" then, it may well make rebasing more of an issue..

orwin 3y ago
Maybe you've only worked with average to good devs who communicate well, like I do now, but I guarantee that in our field, we have people who can at the same time be bad to average AND bad communicators (or worse, toxic liars). Luckily, now our worse communicator is also our most competent dev, but I've been in teams where learning basic git would be a month long challenge for half the people, and for half of those (two people, really, we were 9) communicating their difficulties, or worse, their mistakes was impossible.

smitty1e 3y ago

For now. The insistence that some future researcher may not care is myopic.

binary132 3y ago

Not true, I care. I read history to try to understand features and evolutions and bugs and people.