4 ms·

Here is my last five commit messages: "width*height is area", "fixing stuff i broke", "rm properties we dont need", "rm more useless attributes", "nicer figures

Here is my last five commit messages: "width*height is area", "fixing stuff i broke", "rm properties we dont need", "rm more useless attributes", "nicer figures". I do my best to keep the code base as clean as possible, but I couldn't care less about keeping the commit history pretty. Any time spent on prettifying git history is better spent on documenting the existing* code imo.

kyleee 5y ago
i think this can be true, in some cases the git history may never be looked at so agree effort may be better soent elsewhere
sodapopcan 5y ago
It depends on the project. An open source library should probably have a sane history, a closed-source application, in a lot of cases it doesn't matter so much and often useful to see the whole workflow.
- RussianCow 5y ago
  Why would it matter whether the repo was for an open source library or a closed-source application? That seems like an arbitrary distinction.
  - jmeanz 5y ago
    To me, it doesn’t seem arbitrary at all. Depending on the team size, a closed-source application likely has a small number of other developers that have a vested interest (or access, for that matter). Whereas an open-source project could potentially have orders of magnitude higher number of readers. A much larger audience would warrant higher priority over a readable/clean commit history.
convolvatron 5y ago
thank you for saying this. I'm always afraid to. revision control is a necessary safety net and facilitates discussion around changes (PRs). but people act as if the history is somehow _really really important_. I've seen someone post on HN, apparently seriously, that the history is more important than the source. I know a (potentially) really good developer that spends his time pulling in the recent patches and reorganizing them to make an alternate history that is prettier somehow. sure, every once and a while it because useful/necessary to bisect, and a 'clean' history might help with that. but seriously - why do we fetishize this? this is a medium where the amount of writing vastly outweighs the amount of reading. when people are looking for a bug do they seriously find value in seeing how the code evolved? or do they just figure out why it doesn't work? is there an implicit assumption that the code all worked at some point and the task is to find out when/how it was broken? just really confused
- 74ls00 5y ago
  Yes, going back and understanding why something broke/has changed is incredibly valuable. Often it's not because of one singular decision but a collection of decisions over time that resulted in some behavioural regression. Being able to easily hop through all the commits of the recent past is incredibly valuable for me to understand how we can prevent such errors in the future, not just patch over the current one and move on. Fixing things without considering how we got here I tend to find leads to messy code; extra checks and assertions that aren't necessary if one takes the time to update the underlying assumption or modules that end up too tightly coupled because an extra bit of logic is added to fix that one bug. Obviously it's possible to go too far; not every commit needs an attached essay. Many of my commits are just "fixed typo" or "added unit test for X", but then sometimes I'll write a short paragraphs or two explaining my rationale, referencing the commits that came before
- 8b16380d 5y ago
  Yeah I love picking my way thru junk commits/comments. You may as well not use VCS.
  - convolvatron 5y ago
    what were you hoping to accomplish in the first place?
    - 8b16380d 5y ago
      I look thru history when I am building on top of stuff that already exists. In a complex system that has been around for a while, how else do can you figure things out?

kyleee 5y ago

i think this can be true, in some cases the git history may never be looked at so agree effort may be better soent elsewhere

sodapopcan 5y ago

It depends on the project. An open source library should probably have a sane history, a closed-source application, in a lot of cases it doesn't matter so much and often useful to see the whole workflow.

RussianCow 5y ago
Why would it matter whether the repo was for an open source library or a closed-source application? That seems like an arbitrary distinction.
- jmeanz 5y ago
  To me, it doesn’t seem arbitrary at all. Depending on the team size, a closed-source application likely has a small number of other developers that have a vested interest (or access, for that matter). Whereas an open-source project could potentially have orders of magnitude higher number of readers. A much larger audience would warrant higher priority over a readable/clean commit history.

convolvatron 5y ago

thank you for saying this. I'm always afraid to. revision control is a necessary safety net and facilitates discussion around changes (PRs). but people act as if the history is somehow _really really important_. I've seen someone post on HN, apparently seriously, that the history is more important than the source. I know a (potentially) really good developer that spends his time pulling in the recent patches and reorganizing them to make an alternate history that is prettier somehow. sure, every once and a while it because useful/necessary to bisect, and a 'clean' history might help with that. but seriously - why do we fetishize this? this is a medium where the amount of writing vastly outweighs the amount of reading. when people are looking for a bug do they seriously find value in seeing how the code evolved? or do they just figure out why it doesn't work? is there an implicit assumption that the code all worked at some point and the task is to find out when/how it was broken? just really confused

74ls00 5y ago
Yes, going back and understanding why something broke/has changed is incredibly valuable. Often it's not because of one singular decision but a collection of decisions over time that resulted in some behavioural regression. Being able to easily hop through all the commits of the recent past is incredibly valuable for me to understand how we can prevent such errors in the future, not just patch over the current one and move on. Fixing things without considering how we got here I tend to find leads to messy code; extra checks and assertions that aren't necessary if one takes the time to update the underlying assumption or modules that end up too tightly coupled because an extra bit of logic is added to fix that one bug. Obviously it's possible to go too far; not every commit needs an attached essay. Many of my commits are just "fixed typo" or "added unit test for X", but then sometimes I'll write a short paragraphs or two explaining my rationale, referencing the commits that came before
8b16380d 5y ago
Yeah I love picking my way thru junk commits/comments. You may as well not use VCS.
- convolvatron 5y ago
  what were you hoping to accomplish in the first place?
  - 8b16380d 5y ago
    I look thru history when I am building on top of stuff that already exists. In a complex system that has been around for a while, how else do can you figure things out?