4 ms·

I'm not the person you asked, but I often don't. I personally don't care about git history - I read code not commit messages. I don't really care how it got the

by sfn42 1y ago

I'm not the person you asked, but I often don't. I personally don't care about git history - I read code not commit messages. I don't really care how it got the way it is I care about what it is, maybe once in a blue moon there could potentially be some useful information in a commit message but it's not enough. So, I'll often just make lots of changes and then commit them all at once with some vague commit message and that's that. Nobody cares. If I want to tell people why the code is the way it is I'll just add a comment. This is how I work. I have tried to be more disciplined with commits and stuff like that but I find that it just slows me down and makes the work feel more difficult. I also frequently just forget and find myself having made lots of changes without any commits so then I have to retroactively split it up into commits which can be difficult too. So I'd rather just not worry about it, focus on getting good work done and move on rather than obsess over a git history that's unlikely to ever be read by anyone. I realize that's a self-fulfilling prophecy in that it'd be more likely to be read if it was useful and well done but it's not just me. If I was in a team where everyone did it really well I'd try to keep my own work up to par. But usually I'm the one who cares most about how we do things and this just doesn't seem important to me.

imiric 1y ago
> I personally don't care about git history - I read code not commit messages. Honest question: why do you even use version control? What do you get out of it? Based on your workflow, you could just as well not use it at all, and create zip files and multiple copies of files with names like `_final3_working_20250925`. Change history is the entire point of version control. It gives you the ability to revert to a specific point in time, to branch off and work on experiments, to track down the source of issues, and, perhaps most useful of all, to see why a specific change was done. A commit gives you the ability to add metadata to a change that would be out of place in the code itself. This is often the best place to describe why the change was done, and include any background or pertinent information that can help future developers—including yourself—in many ways. Adding this to the code base in a comment or another document would be out of place, and difficult to manage and discover. You may rarely need to use these abilities, but when you do, they are invaluable IME. And if you don't have them at that point, you'll be kicking yourself for not leveraging a VCS to its full potential. > I have tried to be more disciplined with commits and stuff like that but I find that it just slows me down and makes the work feel more difficult. Of course it slows you down. Taking care of development history requires time and effort, but the ROI of doing that is many times greater. I encourage you to try to be disciplined for a while, and see how you feel about it. I use conventional commits and create atomic commits with descriptive messages even on personal projects that nobody else will work on. Mainly because it gives me the chance to reflect on changes, and include information that will be useful to my future self, months or years from now, after I inevitably abandon the project and eventually get back to it. Here is an example from a project I was working on recently[1]. It's practically a blog post, but it felt good to air my grievances. :) [1]: https://github.com/hackfixme/sesame/commit/10cd8597559b5f4785c11d693ae03a3f8c063d48 https://github.com/hackfixme/sesame/commit/10cd8597559b5f478...
- mixmastamyk 1y ago
  We use it to save our progress, backup files, communicate with others. You know, the main benefits of version control? Writing a story no one will ever see is not one of them. Write real docs and your PM, QA, SMEs will benefit as well, not only developers who bother to dig thru the history.
  - imiric 1y ago
    > We use it to save our progress Saving progress is useless if your history is a mess and you have no idea what a previous state contains. > backup files, communicate with others. You do know that there are better tools than a VCS specifically built for these use cases, right? > You know, the main benefits of version control? No, I don't think you understand what version control is for. You can use a knife to open a wine bottle, but that doesn't mean it's a good idea. > Writing a story no one will ever see is not one of them. You won't. I definitely will, and I take the liberty to be as verbose as I need in personal projects. > Write real docs and your PM, QA, SMEs will benefit as well, not only developers who bother to dig thru the history. You should write "real docs", but that's not what commit messages are for. They're not meant to be read by non-developers either. And developers don't have to "dig thru the history" to see them. Commits are easily referenced and accessible.
    - rowanG077 1y ago
      IF you truly think the main point of version control is to maintain a coherent commit history than you are deluded. For most teams if it can do: 1. allow collaboration 2. Have branching and merging 3. Have diffs between two points in time/branches/tags 4. Allow release tagging it is enough to work with it. Not to say that a coherent git history is great, but to call it the main point is something else. As that is definitely not how a lot of teams are using git or any version control.
    - mixmastamyk 1y ago
      > Saving progress is useless if your history is a mess… Nope, it works, commit! Tests pass, commit! Push. You’ve demonstrated you don’t know what version control is for. Cleaning up the past is a peripheral nicety, that is not at all core. In fact some situations prefer history not be changed at all.
singpolyma3 1y ago
If there is only useful information in the commit message "once in a blue moon" it means someone isn't writing good commit messages. The number of times I look at a change and all I can think is "why did they/I do that" is very very often. Having the answer to that question available saves re learning the lesson that led to the change.
- mixmastamyk 1y ago
  Put that in the developer-docs/issue-tracker where it has chance of being seen again. And not only by developers.
  - singpolyma3 1y ago
    Commit messages are the developer docs for a change yes
pepoluan 1y ago
The important thing about making commits separately and as much self-contained as possible is to allow cherrypicking. Say you're on a development branch and you added something new, that the Project thinks can be and should be added to the Main branch. By having that addition in its own self-contained commit allows the Project to create a new branch, cherrypick the commit, and merge the branch to Main, without having to pull in the rest of the development branch. It's of course not really necessary if you're the only person doing all the development, but it's just a good etiquette if you're working with other people in the Project.
- theshrike79 1y ago
  Only when you commit to main. When I'm creating a PR in a feature branch, it's my playground. And the PR will be squashed and merged as one clean commit with a clean message. Nobody wants to see my 50 "argh, forgot this bit" commits, they bring zero value.

by sfn42 1y ago

imiric 1y ago

> I personally don't care about git history - I read code not commit messages. Honest question: why do you even use version control? What do you get out of it? Based on your workflow, you could just as well not use it at all, and create zip files and multiple copies of files with names like `_final3_working_20250925`. Change history is the entire point of version control. It gives you the ability to revert to a specific point in time, to branch off and work on experiments, to track down the source of issues, and, perhaps most useful of all, to see why a specific change was done. A commit gives you the ability to add metadata to a change that would be out of place in the code itself. This is often the best place to describe why the change was done, and include any background or pertinent information that can help future developers—including yourself—in many ways. Adding this to the code base in a comment or another document would be out of place, and difficult to manage and discover. You may rarely need to use these abilities, but when you do, they are invaluable IME. And if you don't have them at that point, you'll be kicking yourself for not leveraging a VCS to its full potential. > I have tried to be more disciplined with commits and stuff like that but I find that it just slows me down and makes the work feel more difficult. Of course it slows you down. Taking care of development history requires time and effort, but the ROI of doing that is many times greater. I encourage you to try to be disciplined for a while, and see how you feel about it. I use conventional commits and create atomic commits with descriptive messages even on personal projects that nobody else will work on. Mainly because it gives me the chance to reflect on changes, and include information that will be useful to my future self, months or years from now, after I inevitably abandon the project and eventually get back to it. Here is an example from a project I was working on recently[1]. It's practically a blog post, but it felt good to air my grievances. :) [1]: https://github.com/hackfixme/sesame/commit/10cd8597559b5f4785c11d693ae03a3f8c063d48 https://github.com/hackfixme/sesame/commit/10cd8597559b5f478...

mixmastamyk 1y ago
We use it to save our progress, backup files, communicate with others. You know, the main benefits of version control? Writing a story no one will ever see is not one of them. Write real docs and your PM, QA, SMEs will benefit as well, not only developers who bother to dig thru the history.
- imiric 1y ago
  > We use it to save our progress Saving progress is useless if your history is a mess and you have no idea what a previous state contains. > backup files, communicate with others. You do know that there are better tools than a VCS specifically built for these use cases, right? > You know, the main benefits of version control? No, I don't think you understand what version control is for. You can use a knife to open a wine bottle, but that doesn't mean it's a good idea. > Writing a story no one will ever see is not one of them. You won't. I definitely will, and I take the liberty to be as verbose as I need in personal projects. > Write real docs and your PM, QA, SMEs will benefit as well, not only developers who bother to dig thru the history. You should write "real docs", but that's not what commit messages are for. They're not meant to be read by non-developers either. And developers don't have to "dig thru the history" to see them. Commits are easily referenced and accessible.
  - rowanG077 1y ago
    IF you truly think the main point of version control is to maintain a coherent commit history than you are deluded. For most teams if it can do: 1. allow collaboration 2. Have branching and merging 3. Have diffs between two points in time/branches/tags 4. Allow release tagging it is enough to work with it. Not to say that a coherent git history is great, but to call it the main point is something else. As that is definitely not how a lot of teams are using git or any version control.
  - mixmastamyk 1y ago
    > Saving progress is useless if your history is a mess… Nope, it works, commit! Tests pass, commit! Push. You’ve demonstrated you don’t know what version control is for. Cleaning up the past is a peripheral nicety, that is not at all core. In fact some situations prefer history not be changed at all.

singpolyma3 1y ago

If there is only useful information in the commit message "once in a blue moon" it means someone isn't writing good commit messages. The number of times I look at a change and all I can think is "why did they/I do that" is very very often. Having the answer to that question available saves re learning the lesson that led to the change.

mixmastamyk 1y ago
Put that in the developer-docs/issue-tracker where it has chance of being seen again. And not only by developers.
- singpolyma3 1y ago
  Commit messages are the developer docs for a change yes

pepoluan 1y ago

The important thing about making commits separately and as much self-contained as possible is to allow cherrypicking. Say you're on a development branch and you added something new, that the Project thinks can be and should be added to the Main branch. By having that addition in its own self-contained commit allows the Project to create a new branch, cherrypick the commit, and merge the branch to Main, without having to pull in the rest of the development branch. It's of course not really necessary if you're the only person doing all the development, but it's just a good etiquette if you're working with other people in the Project.

theshrike79 1y ago
Only when you commit to main. When I'm creating a PR in a feature branch, it's my playground. And the PR will be squashed and merged as one clean commit with a clean message. Nobody wants to see my 50 "argh, forgot this bit" commits, they bring zero value.