4 ms·

Squashing is nice IMHO, and even a must after a while. For one recent very small project a squash of the commit history reduced the storage from tens of kilobyt

Squashing is nice IMHO, and even a must after a while. For one recent very small project a squash of the commit history reduced the storage from tens of kilobytes to a few hundred bytes total. Orders of magnitude. That was a very small project, so imagine the storage space savings for larger projects. I find that the commit history tends to grow viciously for anything I've been involved with. And I fail to see the benefit of amassing that amount of detail once you are past the stages where each individual commit is reversible (or even interesting) So, for a project that runs for, say, three months, the commits of the first few weeks aren't really very interesting or valuable at all at the end of the period. Just hard drive space being eaten up. YMMV.

erik_seaberg 3y ago
Real example: I had to mitigate an outage in the middle of the night, and I found the root cause in ten lines of code. I needed very badly to “git blame” that code and find a specific commit message from three years ago and its author (a former colleague), to figure out what he had been trying to do. Right now I have a full clone of a pretty large monorepo dating back almost nine years, and the .git dir is less than half of the total space. Sparse checkouts and shallow clones can make clown car hardware sort of work, but I do not want to go back to the pre-git days and try to work without full history to conserve 0.008 TB of SSD. We spend more than that on coffee.
- JoshTriplett 3y ago
  Exactly. Storage space is much cheaper than human time and brainpower.
- yetanother12345 3y ago
  Ok, so it appears we just approach some problems differently. If I had to work in the middle of the night and found a problem spanning ten LOC my procedure would be "fix, commit, back to sleep". I would never feel any need (nor have the time) to investigate the origin of the problem, much less feel a need to "git blame" anyone. Likely I would not even look at the commit history as (to me) historical code is not really relevant from a current-problem-solving standpoint. But that's just me I guess. > make clown car hardware I'm not a native English speaker so this appears to me as a bit confrontational and/or an attempt to ridicule me or the points that I am making? I do not work with clowns, cars, or hardware. > full history I can see one benefit, and that is the case of sensitive software for special use (eg govt. mil, etc). Here, I agree that in the case of a vuln being discovered it could be a good thing to go back and trace the origin. So, I'm not opposed to keeping history, it's just not relevant to any particular extent for the types of tasks I do in my current $job. My stance is more like, if I'll never use any of this stuff, why keep it at all? It's not about costs it's just keeping things simple
  - erik_seaberg 3y ago
    A clown car is comically small for its use (the joke is that it arrives and clowns keep getting out, seemingly more than could have been inside). I’m sorry, I didn’t mean you as a poster, but someone else who is hiring professionals while under-specifying hardware they provide you. Storing source code is not a problem you should have reason to worry about. The problem with “fix it now” is that I didn’t know for sure that our behavior was wrong, I just knew that a consumer of our microservice had begun alerting on errors. I had to find out whether this was a mistake (which maybe I could safely fix) or important and intended (and any change must be negotiated with other consumers). It comes with having an old, complex system with a lot of dependencies and without exhaustive documentation.
    - Volundr 3y ago
      I can't count how many times this has happened to me. Trace an issue down to some piece of code that makes it look very intentional, then have to go spelunking through whatever history I can find to figure out what the actual correct specified behavior is. Bonus fun when you have to start reaching out to clients to find out if anyone is relying on it acting that way.

erik_seaberg 3y ago

Real example: I had to mitigate an outage in the middle of the night, and I found the root cause in ten lines of code. I needed very badly to “git blame” that code and find a specific commit message from three years ago and its author (a former colleague), to figure out what he had been trying to do. Right now I have a full clone of a pretty large monorepo dating back almost nine years, and the .git dir is less than half of the total space. Sparse checkouts and shallow clones can make clown car hardware sort of work, but I do not want to go back to the pre-git days and try to work without full history to conserve 0.008 TB of SSD. We spend more than that on coffee.

JoshTriplett 3y ago
Exactly. Storage space is much cheaper than human time and brainpower.
yetanother12345 3y ago
Ok, so it appears we just approach some problems differently. If I had to work in the middle of the night and found a problem spanning ten LOC my procedure would be "fix, commit, back to sleep". I would never feel any need (nor have the time) to investigate the origin of the problem, much less feel a need to "git blame" anyone. Likely I would not even look at the commit history as (to me) historical code is not really relevant from a current-problem-solving standpoint. But that's just me I guess. > make clown car hardware I'm not a native English speaker so this appears to me as a bit confrontational and/or an attempt to ridicule me or the points that I am making? I do not work with clowns, cars, or hardware. > full history I can see one benefit, and that is the case of sensitive software for special use (eg govt. mil, etc). Here, I agree that in the case of a vuln being discovered it could be a good thing to go back and trace the origin. So, I'm not opposed to keeping history, it's just not relevant to any particular extent for the types of tasks I do in my current $job. My stance is more like, if I'll never use any of this stuff, why keep it at all? It's not about costs it's just keeping things simple
- erik_seaberg 3y ago
  A clown car is comically small for its use (the joke is that it arrives and clowns keep getting out, seemingly more than could have been inside). I’m sorry, I didn’t mean you as a poster, but someone else who is hiring professionals while under-specifying hardware they provide you. Storing source code is not a problem you should have reason to worry about. The problem with “fix it now” is that I didn’t know for sure that our behavior was wrong, I just knew that a consumer of our microservice had begun alerting on errors. I had to find out whether this was a mistake (which maybe I could safely fix) or important and intended (and any change must be negotiated with other consumers). It comes with having an old, complex system with a lot of dependencies and without exhaustive documentation.
  - Volundr 3y ago
    I can't count how many times this has happened to me. Trace an issue down to some piece of code that makes it look very intentional, then have to go spelunking through whatever history I can find to figure out what the actual correct specified behavior is. Bonus fun when you have to start reaching out to clients to find out if anyone is relying on it acting that way.