3 ms·

This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to s

by rwmj 3y ago

This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to share your work with anyone else.

loloquwowndueo 3y ago
Dunno, I’ve spent countless hours carefully grooming my git commit histories so they make sense and convey a coherent story, just to have them destroyed by some squash zealot at merge time . “Squash before merge” workflows seem to be more common these days and I have to think it’s mostly a push by people who do not know how to do interactive rebases and history rewrites.
- Aissen 3y ago
  You did the right thing, and I'm sorry this happened to you. May you only have to contribute to non-squashing projects in the future.
- tempest_ 3y ago
  I find it has more to do with people (myself included) who interact with git at a PR/MR level. If your PRs are small and you interact with git a lot using some web portal it sort of pushes you this way.
- skydhash 3y ago
  Squash before merge is fine if you have a project tracker, where you can use the issue as a discussion hub to describe your thoughts. Then you put the issue number in the squashed commit message. The PR can serve as implementation specific documentation and discussion.
  - loloquwowndueo 3y ago
    I disagree: discussion in a ticket or issue tends to be as disorganized as the random series of commits that are frowned upon in “nice commit history” workflows. It’s just sweeping the mess to another place where it can’t easily be found. But it’s okay, I gave up trying to convince people. So I’ll just disagree and commit (pun intended).
PurpleRamen 3y ago
What's the worth of a commit-message? The code, it's documentation and the associated issue-number is enough information. Or are people just not using their other tools for communicating those things?
- BanazirGalbasi 3y ago
  Why did you make this commit? What was the reason that made you stage these particular files and their changes and commit them to the repo? What were you trying to fix, add, or change? I rarely see that documented in comments because it changes constantly, and documentation tends to be for users. An issue number can have that information, but if you're going to be tracking changes in git anyway why not use the system as designed so people don't have to hop to a different system to get a quick understanding of the commit?
  - PurpleRamen 3y ago
    > documentation tends to be for users. There is user documentation and there is technical documentation. Both are very different. Unless you have a lib, framework or such, in which case it's more or less the same. > but if you're going to be tracking changes in git anyway Yes, it's a technical system for tracking changes, not documenting those changes on the developer-level. > so people don't have to hop to a different system to get a quick understanding of the commit? Because for any meaningful complex product you need to do that anyway. commit-messages are just the bare minimum of ways to document. Though, of course, you can make more use of it, including it in some semi-automatic changelog and such. But usually it's not worth the hazzle.
    - BanazirGalbasi 3y ago
      > tracking changes, not documenting those changes Documenting changes is part of tracking them. Yes, there is the code itself, but explaining those changes allows for following the development path. Do you expect everyone to read every line of code to understand every commit? > commit-messages are just the bare minimum of ways to document Single-line messages, yes. Multi-line commit messages are plenty for commit messages because they let you add more context about the changes. I'd like to point out that it's possible for there to be multiple commits for a single issue - maybe the first one didn't fix it, or maybe there's multiple components being fixed. Simply pointing back to the issue won't give enough relevant information about each commit, it will simply say what the group of commits as a whole is supposed to do. If it turns out that fixing that issue caused others to occur, then the individual commit messages are going to be more useful for diagnosing the new problem than a single lump issue conversation will be. I agree that there should be more documentation for a project than just git commits, I just think you're wildly estimating how useful commit messages really can be.
user3939382 3y ago
We do one person per branch with rare exception. When trying to piece together past changes while debugging I basically don’t care what the commit messages are, I use JetBrains’ “show history for selection” in most cases. Much more useful to me than the messages is the changeset file name highlighting so I can see which files I’ve touched for the thing I’m trying to accomplish right this second. Pushing resets that. So the push is based on “I’m thinking about a new thing now”. Often my commit messages are “x” because there is no cohesion to anything since my last push, I went around making a bunch of nit picks while exploring some code path(s). If it works for me and my team, it’s the right way. Same for everyone else.

by rwmj 3y ago

This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to share your work with anyone else.

loloquwowndueo 3y ago

Dunno, I’ve spent countless hours carefully grooming my git commit histories so they make sense and convey a coherent story, just to have them destroyed by some squash zealot at merge time . “Squash before merge” workflows seem to be more common these days and I have to think it’s mostly a push by people who do not know how to do interactive rebases and history rewrites.

Aissen 3y ago
You did the right thing, and I'm sorry this happened to you. May you only have to contribute to non-squashing projects in the future.
tempest_ 3y ago
I find it has more to do with people (myself included) who interact with git at a PR/MR level. If your PRs are small and you interact with git a lot using some web portal it sort of pushes you this way.
skydhash 3y ago
Squash before merge is fine if you have a project tracker, where you can use the issue as a discussion hub to describe your thoughts. Then you put the issue number in the squashed commit message. The PR can serve as implementation specific documentation and discussion.
- loloquwowndueo 3y ago
  I disagree: discussion in a ticket or issue tends to be as disorganized as the random series of commits that are frowned upon in “nice commit history” workflows. It’s just sweeping the mess to another place where it can’t easily be found. But it’s okay, I gave up trying to convince people. So I’ll just disagree and commit (pun intended).

PurpleRamen 3y ago

What's the worth of a commit-message? The code, it's documentation and the associated issue-number is enough information. Or are people just not using their other tools for communicating those things?

BanazirGalbasi 3y ago
Why did you make this commit? What was the reason that made you stage these particular files and their changes and commit them to the repo? What were you trying to fix, add, or change? I rarely see that documented in comments because it changes constantly, and documentation tends to be for users. An issue number can have that information, but if you're going to be tracking changes in git anyway why not use the system as designed so people don't have to hop to a different system to get a quick understanding of the commit?
- PurpleRamen 3y ago
  > documentation tends to be for users. There is user documentation and there is technical documentation. Both are very different. Unless you have a lib, framework or such, in which case it's more or less the same. > but if you're going to be tracking changes in git anyway Yes, it's a technical system for tracking changes, not documenting those changes on the developer-level. > so people don't have to hop to a different system to get a quick understanding of the commit? Because for any meaningful complex product you need to do that anyway. commit-messages are just the bare minimum of ways to document. Though, of course, you can make more use of it, including it in some semi-automatic changelog and such. But usually it's not worth the hazzle.
  - BanazirGalbasi 3y ago
    > tracking changes, not documenting those changes Documenting changes is part of tracking them. Yes, there is the code itself, but explaining those changes allows for following the development path. Do you expect everyone to read every line of code to understand every commit? > commit-messages are just the bare minimum of ways to document Single-line messages, yes. Multi-line commit messages are plenty for commit messages because they let you add more context about the changes. I'd like to point out that it's possible for there to be multiple commits for a single issue - maybe the first one didn't fix it, or maybe there's multiple components being fixed. Simply pointing back to the issue won't give enough relevant information about each commit, it will simply say what the group of commits as a whole is supposed to do. If it turns out that fixing that issue caused others to occur, then the individual commit messages are going to be more useful for diagnosing the new problem than a single lump issue conversation will be. I agree that there should be more documentation for a project than just git commits, I just think you're wildly estimating how useful commit messages really can be.

user3939382 3y ago

We do one person per branch with rare exception. When trying to piece together past changes while debugging I basically don’t care what the commit messages are, I use JetBrains’ “show history for selection” in most cases. Much more useful to me than the messages is the changeset file name highlighting so I can see which files I’ve touched for the thing I’m trying to accomplish right this second. Pushing resets that. So the push is based on “I’m thinking about a new thing now”. Often my commit messages are “x” because there is no cohesion to anything since my last push, I went around making a bunch of nit picks while exploring some code path(s). If it works for me and my team, it’s the right way. Same for everyone else.