3 ms·

How is the history relevant? Honest question. 5 years in the field I never had a reason to check out the git history of any project I ever worked on.

cpuguy83 3mo ago
Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?
- sevenzero 3mo ago
  Why would that matter if a bug is uncovered? If you know there's a bug just fix it? Like what use does the bugs history have?
  - afavour 3mo ago
    Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality. A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.
    - sevenzero 3mo ago
      Guess I must be doing something wrong to never have encountered this issue in my 5 years.
      - loeg 3mo ago
        As you get better at engineering and grow into a senior, you'll find this more valuable.
      - afavour 3mo ago
        You do you. But in my twenty years I’ve leaned on it countless times.
      - klibertp 3mo ago
        I would ignore it if I spotted it once. This is the second time, though, so I probably should point it out: 5 years is a very short time in terms of personal experience and development. While the whole industry moves very fast, it does so thanks to slow, grinding effort parallelized over hundreds of thousands of individuals. For an organization, 5 years is an era. For individuals, it's just 3-6 projects (+/- a few, depending on the context you work in). TL;DR: "never have encountered in 5 years" is a meaningless data point. My professional career can legally drink beer since a few years back, yet I'm still regularly hitting "first times" on various things in my day job; I'm also frequently mind-blown reading about others' experiences in domains I never touched. Don't make those "5 years" into a badge to hide behind; use it as a springboard to reach higher. In this case, try to actively think of uses for the commit history. It's already there; there's an expectation (admittedly, to various degrees depending on context) that it will be maintained. Try to maximize the value you get out of it. Underutilizing a tool you have access to may not be that much of a problem on average, but in some specific circumstances can make a difference between being able to complete a task at all or not. You shouldn't rely on luck to never land in a situation like that: familiarizing yourself with as many potential uses for a tool as possible gives you a better chance of handling it more easily. EDIT: formatting, last paragraph.
      - vlovich123 3mo ago
        You can of course choose alternate strategies. It comes up a lot when doing low level systems programming because the bugs can be non-trivial to repro and root cause (particularly for C/C++ where you have segfaults and whatnot). So it’s cheaper and faster to try a bisect to find the regression introduction as an additional clue in the root cause analysis (eg ownership rules changed or there were changes that looked correct regarding threading but when you hyper focus on it you realize what the problem is). Or you’re working on a high performance codebase and there was a performance regression - it can be faster to bisect than it is to try to find the issue with profiling tools (I had this and seen issues where profiling tools would never have told you the issue).
      - cscheid 3mo ago
        I'm just going to answer this one candidly. Yes, you are doing something wrong. Immediately: the commit history is useful to understand the context in which a bug was introduced, because it's the best context to understand the _reason_ the mistake was maybe, which is a really good way to prevent regressions. But more generally: when an entire industry has arrived at an accepted practice, you the junior developer (sorry, 5 years is _nothing_: you need to be told this too) have a chance to pick up on it. Have you heard "have you played guitar for 20 years, or have you played guitar 20 times for a year?" Time only helps with accumulating wisdom if you let it.
      - VBprogrammer 3mo ago
        It depends on the size of the project (mostly in terms of number of active developers) and how close you are to the running code in production. On a large project it's probably the first tool I reach for when we find something we have reason to believe was a recently introduced bug. Specifically annotating (git blame) the relevant code and scanning for what lines have been recently modified. I've worked in startups where there were only 2 backend devs and a frontend guy. There it was almost completely irrelevant and I spent a couple of years at a large software shop, early in my career, where bugs in production code was mostly someone else's problem.
      - ShinTakuya 3mo ago
        I'm tempted to suggest you have encountered the issue but your team mates are shielding you from the consequences (with or without their knowledge).
        sevenzero 3mo ago
        What teammates?
        ShinTakuya 3mo ago
        Well that would explain why you wouldn't need a git history.
      - jeltz 3mo ago
        Probably, because in my 20 year career I have encountered it plenty except back the first couple of years as a junior developer when I did not know my tools and did not know that I should do this.
    - klibertp 3mo ago
      > A git commit [ideally] gives you the reason for the change FTFY ;) I broadly agree, but it's important to note that, in practice, Git commits are hit and miss: they might save you a lot of time if they are well-structured and described properly, but they might also completely fail to give you anything of value (for the problem you're facing at the moment). Turning Git history into a broadly useful artifact requires a lot of discipline from everyone working on a codebase over its lifetime. It's never totally useless, but it's often less helpful than it could be. Recently, I turned to JJ for this exact reason: crafting a meaningful change history is much easier there, especially if you need to retrofit it after you're done with the implementation. jj's split, squash, and describe are a joy to work with, also because the interactive version lets you easily split or squash hunks (selected changes in the same file).
      - afavour 3mo ago
        Fair. Though I find it works well when commits get squished at the PR level. That way you have a link to a (hopefully!) detailed overview of what happened, when and why.
  - StilesCrisis 3mo ago
    You can see what the code looked like before the bug was added, and in many cases, just change it back to how it used to be? The most obvious use case for history is "roll back this entire CL, it's broken".
  - deleted 3mo ago
    [deleted]
  - PennRobotics 3mo ago
    "Bug uncovered" doesn't mean "bug fixed." Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions. At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't even be able to download and build Wine 9.21 staging, when yabridge worked. Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends. (I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.) I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.
    - vlovich123 3mo ago
      > I understand Wine avoiding the flag solution I don’t - Windows keeps a compatibility database for a reason. It seems inevitable that you’d need to maintain that too to keep apps working or drop support. The performance is a non-sequiter for a few reasons. Even in the hot path the conditional is going to get speculated away since the wine subsystem is uniquely instantiated per application. If you were really paranoid you could ship multiple binaries and select which ones to use dynamically at runtime. I suspect the bigger problem is one of maintenance - Microsoft does this with a huge budget and a huge team whose sole responsibility is maintaining that comparability. A community project is going to have to make more pragmatic choices.
  - cyberrock 3mo ago
    Diagnosing why a bug happened is interesting. Sometimes it points to a communication shortcoming that the project/organization should strive to improve on. Of course, if you're slinging code with a few buddies, it might not matter. In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.
  - skeledrew 3mo ago
    Chesterton's Fence.
Shatnerz 3mo ago
Checking git history is one of the first things I do when I find unfamiliar code or when I'm debugging something. Git history contains a lot of context that helps speed up the rest of the process
benrutter 3mo ago
Simple but pretty common use case: If you're ever looking at some pre-existing code and thinking "I don't really get why it's written like this?", you can get a lot out of looking through the git blame/history. Often "weird design" is there for historic reasons around stuff like backwards compatibility. If your project has a well managed commit log, you can find the notes of whoever implemented it, possibly even with their motivation for doing so. At the very least, you can find out who wrote that code and ask them about it. There's a tonne of data in git histories - this article was shared a few months back and is an awesome example of some things you can do with git history: https://piechowski.io/post/git-commands-before-reading-code/ https://piechowski.io/post/git-commands-before-reading-code/
- sevenzero 3mo ago
  That actually is helpful, but it would require a git history that actually makes sense. I rarely encounter well thought out git histories. For me its often just dev ramblings or 10 word commit messages
  - fg137 3mo ago
    If I can choose "badly maintained history" and "no history" I'll choose the former every time. That's even less of a problem when Claude can do a first pass for you.
    - sevenzero 3mo ago
      Claude can smd
owaislone 3mo ago
Enables the best git command ever: git bisect
- imron 3mo ago
  Yes! An incredible tool. You'll rarely need to use it, but when you do it's invaluable.
taybin 3mo ago
There are several possible reasons for that, but I'll just say it's a very common use case. It's actually the one of the original use cases for SCSs. How else could you revert to a prior commit?
pastakatsu 3mo ago
You've truly never come across a single thing you've gone to "fix" only to have it break stuff and then explained why it needs to stay that way in a commit message?
simonw 3mo ago
I look at history all the time. Why is the code like this? Usually git blame will show me either a commit message with extra context or a link to an issue thread. When was this bug first introduced? Git bisect can track it down almost automatically. If you're never looking at history you're missing out on a lot of the value Git provides. It's more then just a backup tool.
flohofwoe 3mo ago
You never run a git blame or git bisect to find out when and under which circumstances a regression or bug was introduced, and why this specific change was made? That might work for a while on a personal project, but is essential in a team project. It's not uncommon that by fixing a bug you also accidentially undo an actually intended change. Doing some software archeology in the git history and tracing back the steps that led to the bug/regression usually prevents that sort of thing. You'd also want to notify the person who introduced the bug (and if this is a good and honorable chap, they'll fix the bug themselves).

cpuguy83 3mo ago

Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?

sevenzero 3mo ago
Why would that matter if a bug is uncovered? If you know there's a bug just fix it? Like what use does the bugs history have?
- afavour 3mo ago
  Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality. A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.
  - sevenzero 3mo ago
    Guess I must be doing something wrong to never have encountered this issue in my 5 years.
    - loeg 3mo ago
      As you get better at engineering and grow into a senior, you'll find this more valuable.
    - afavour 3mo ago
      You do you. But in my twenty years I’ve leaned on it countless times.
    - klibertp 3mo ago
      I would ignore it if I spotted it once. This is the second time, though, so I probably should point it out: 5 years is a very short time in terms of personal experience and development. While the whole industry moves very fast, it does so thanks to slow, grinding effort parallelized over hundreds of thousands of individuals. For an organization, 5 years is an era. For individuals, it's just 3-6 projects (+/- a few, depending on the context you work in). TL;DR: "never have encountered in 5 years" is a meaningless data point. My professional career can legally drink beer since a few years back, yet I'm still regularly hitting "first times" on various things in my day job; I'm also frequently mind-blown reading about others' experiences in domains I never touched. Don't make those "5 years" into a badge to hide behind; use it as a springboard to reach higher. In this case, try to actively think of uses for the commit history. It's already there; there's an expectation (admittedly, to various degrees depending on context) that it will be maintained. Try to maximize the value you get out of it. Underutilizing a tool you have access to may not be that much of a problem on average, but in some specific circumstances can make a difference between being able to complete a task at all or not. You shouldn't rely on luck to never land in a situation like that: familiarizing yourself with as many potential uses for a tool as possible gives you a better chance of handling it more easily. EDIT: formatting, last paragraph.
    - vlovich123 3mo ago
      You can of course choose alternate strategies. It comes up a lot when doing low level systems programming because the bugs can be non-trivial to repro and root cause (particularly for C/C++ where you have segfaults and whatnot). So it’s cheaper and faster to try a bisect to find the regression introduction as an additional clue in the root cause analysis (eg ownership rules changed or there were changes that looked correct regarding threading but when you hyper focus on it you realize what the problem is). Or you’re working on a high performance codebase and there was a performance regression - it can be faster to bisect than it is to try to find the issue with profiling tools (I had this and seen issues where profiling tools would never have told you the issue).
    - cscheid 3mo ago
      I'm just going to answer this one candidly. Yes, you are doing something wrong. Immediately: the commit history is useful to understand the context in which a bug was introduced, because it's the best context to understand the _reason_ the mistake was maybe, which is a really good way to prevent regressions. But more generally: when an entire industry has arrived at an accepted practice, you the junior developer (sorry, 5 years is _nothing_: you need to be told this too) have a chance to pick up on it. Have you heard "have you played guitar for 20 years, or have you played guitar 20 times for a year?" Time only helps with accumulating wisdom if you let it.
    - VBprogrammer 3mo ago
      It depends on the size of the project (mostly in terms of number of active developers) and how close you are to the running code in production. On a large project it's probably the first tool I reach for when we find something we have reason to believe was a recently introduced bug. Specifically annotating (git blame) the relevant code and scanning for what lines have been recently modified. I've worked in startups where there were only 2 backend devs and a frontend guy. There it was almost completely irrelevant and I spent a couple of years at a large software shop, early in my career, where bugs in production code was mostly someone else's problem.
    - ShinTakuya 3mo ago
      I'm tempted to suggest you have encountered the issue but your team mates are shielding you from the consequences (with or without their knowledge).
      - sevenzero 3mo ago
        What teammates?
        ShinTakuya 3mo ago
        Well that would explain why you wouldn't need a git history.
    - jeltz 3mo ago
      Probably, because in my 20 year career I have encountered it plenty except back the first couple of years as a junior developer when I did not know my tools and did not know that I should do this.
  - klibertp 3mo ago
    > A git commit [ideally] gives you the reason for the change FTFY ;) I broadly agree, but it's important to note that, in practice, Git commits are hit and miss: they might save you a lot of time if they are well-structured and described properly, but they might also completely fail to give you anything of value (for the problem you're facing at the moment). Turning Git history into a broadly useful artifact requires a lot of discipline from everyone working on a codebase over its lifetime. It's never totally useless, but it's often less helpful than it could be. Recently, I turned to JJ for this exact reason: crafting a meaningful change history is much easier there, especially if you need to retrofit it after you're done with the implementation. jj's split, squash, and describe are a joy to work with, also because the interactive version lets you easily split or squash hunks (selected changes in the same file).
    - afavour 3mo ago
      Fair. Though I find it works well when commits get squished at the PR level. That way you have a link to a (hopefully!) detailed overview of what happened, when and why.
- StilesCrisis 3mo ago
  You can see what the code looked like before the bug was added, and in many cases, just change it back to how it used to be? The most obvious use case for history is "roll back this entire CL, it's broken".
- deleted 3mo ago
  [deleted]
- PennRobotics 3mo ago
  "Bug uncovered" doesn't mean "bug fixed." Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions. At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't even be able to download and build Wine 9.21 staging, when yabridge worked. Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends. (I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.) I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.
  - vlovich123 3mo ago
    > I understand Wine avoiding the flag solution I don’t - Windows keeps a compatibility database for a reason. It seems inevitable that you’d need to maintain that too to keep apps working or drop support. The performance is a non-sequiter for a few reasons. Even in the hot path the conditional is going to get speculated away since the wine subsystem is uniquely instantiated per application. If you were really paranoid you could ship multiple binaries and select which ones to use dynamically at runtime. I suspect the bigger problem is one of maintenance - Microsoft does this with a huge budget and a huge team whose sole responsibility is maintaining that comparability. A community project is going to have to make more pragmatic choices.
- cyberrock 3mo ago
  Diagnosing why a bug happened is interesting. Sometimes it points to a communication shortcoming that the project/organization should strive to improve on. Of course, if you're slinging code with a few buddies, it might not matter. In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.
- skeledrew 3mo ago
  Chesterton's Fence.

Shatnerz 3mo ago

Checking git history is one of the first things I do when I find unfamiliar code or when I'm debugging something. Git history contains a lot of context that helps speed up the rest of the process

benrutter 3mo ago

Simple but pretty common use case: If you're ever looking at some pre-existing code and thinking "I don't really get why it's written like this?", you can get a lot out of looking through the git blame/history. Often "weird design" is there for historic reasons around stuff like backwards compatibility. If your project has a well managed commit log, you can find the notes of whoever implemented it, possibly even with their motivation for doing so. At the very least, you can find out who wrote that code and ask them about it. There's a tonne of data in git histories - this article was shared a few months back and is an awesome example of some things you can do with git history: https://piechowski.io/post/git-commands-before-reading-code/ https://piechowski.io/post/git-commands-before-reading-code/

sevenzero 3mo ago
That actually is helpful, but it would require a git history that actually makes sense. I rarely encounter well thought out git histories. For me its often just dev ramblings or 10 word commit messages
- fg137 3mo ago
  If I can choose "badly maintained history" and "no history" I'll choose the former every time. That's even less of a problem when Claude can do a first pass for you.
  - sevenzero 3mo ago
    Claude can smd

owaislone 3mo ago

Enables the best git command ever: git bisect

imron 3mo ago
Yes! An incredible tool. You'll rarely need to use it, but when you do it's invaluable.

taybin 3mo ago

There are several possible reasons for that, but I'll just say it's a very common use case. It's actually the one of the original use cases for SCSs. How else could you revert to a prior commit?

pastakatsu 3mo ago

You've truly never come across a single thing you've gone to "fix" only to have it break stuff and then explained why it needs to stay that way in a commit message?

simonw 3mo ago

I look at history all the time. Why is the code like this? Usually git blame will show me either a commit message with extra context or a link to an issue thread. When was this bug first introduced? Git bisect can track it down almost automatically. If you're never looking at history you're missing out on a lot of the value Git provides. It's more then just a backup tool.

flohofwoe 3mo ago

You never run a git blame or git bisect to find out when and under which circumstances a regression or bug was introduced, and why this specific change was made? That might work for a while on a personal project, but is essential in a team project. It's not uncommon that by fixing a bug you also accidentially undo an actually intended change. Doing some software archeology in the git history and tracing back the steps that led to the bug/regression usually prevents that sort of thing. You'd also want to notify the person who introduced the bug (and if this is a good and honorable chap, they'll fix the bug themselves).