4 ms·

This is a Git misfeature more other source control systems didn't share. Svn, Perforce, etc. Name your commits appropriately and don't commit for every comma.

by oblio 4y ago

This is a Git misfeature more other source control systems didn't share. Svn, Perforce, etc. Name your commits appropriately and don't commit for every comma. People learn quickly the lay of the land, if they have to.

pydry 4y ago
>don't commit for every comma You think that lots of tiny commits, each providing an incremental, working improvement to the code is bad practice?
- oblio 4y ago
  What I'm saying and what you're saying are not the same thing. And for your example, if they're measurable improvements you should be able to write a decent commit message.
  - pydry 4y ago
    I could, it would just be a waste of time. IME commit messages are the least looked at form of documentation period.
int_19h 4y ago
Quite the opposite, this is the best feature of Git. Commit often, don't be afraid to experiment since you can always roll back easily even if it's literally just a single comma - and then when it's time to share that code with others, then reorganize history into a sequence of well-named commits with clean description of what each of them does. We don't expect people to give important speeches without writing a draft first, nor do we insist on seeing all their drafts. Why is this any different?
- notdonspaulding 4y ago
  It's different for the same reason math teachers want you to "show your work" in addition to simply writing down the answer to a problem. They way you as a human have approached the problem and worked it out is valuable information in both the review of the work itself and in understanding what has gone wrong when something has gone wrong. Think of your branch as being one long multi-day math problem. If I'm grading your work, I don't want you to show me all the parts you think are neat and tidy and important after you arrive at what you think is the answer. I want to see everything you tried, even the stuff that didn't work. I'm not opposed to only having merge commits on master, but somewhere, on some branch which is recorded for all of time, I want to be able to see every decision that was made to bring HEAD to what it is right now, on the most granular level possible.
  - gsinclair 4y ago
    There is a path between these two points of view. Yes, a maths teacher wants to see the working to a problem, but the working can still be the second draft, written neatly and well explained. For a complicated problem, it should not be expected that someone will read through all the “scratch work”.
    - lucumo 4y ago
      > For a complicated problem, it should not be expected that someone will read through all the “scratch work”. Do people really read through the changelog commit by commit? What's gained by that? I don't read through it at all. I zoom into a point that I need to know more about. I have information (bug report, runtime behaviour on other data) that allows me to zoom into a specific part. The information I have is from the committer's future. It's highly unlikely that the details needed are in the summary that they wrote.

by oblio 4y ago

pydry 4y ago

>don't commit for every comma You think that lots of tiny commits, each providing an incremental, working improvement to the code is bad practice?

oblio 4y ago
What I'm saying and what you're saying are not the same thing. And for your example, if they're measurable improvements you should be able to write a decent commit message.
- pydry 4y ago
  I could, it would just be a waste of time. IME commit messages are the least looked at form of documentation period.

int_19h 4y ago

Quite the opposite, this is the best feature of Git. Commit often, don't be afraid to experiment since you can always roll back easily even if it's literally just a single comma - and then when it's time to share that code with others, then reorganize history into a sequence of well-named commits with clean description of what each of them does. We don't expect people to give important speeches without writing a draft first, nor do we insist on seeing all their drafts. Why is this any different?

notdonspaulding 4y ago
It's different for the same reason math teachers want you to "show your work" in addition to simply writing down the answer to a problem. They way you as a human have approached the problem and worked it out is valuable information in both the review of the work itself and in understanding what has gone wrong when something has gone wrong. Think of your branch as being one long multi-day math problem. If I'm grading your work, I don't want you to show me all the parts you think are neat and tidy and important after you arrive at what you think is the answer. I want to see everything you tried, even the stuff that didn't work. I'm not opposed to only having merge commits on master, but somewhere, on some branch which is recorded for all of time, I want to be able to see every decision that was made to bring HEAD to what it is right now, on the most granular level possible.
- gsinclair 4y ago
  There is a path between these two points of view. Yes, a maths teacher wants to see the working to a problem, but the working can still be the second draft, written neatly and well explained. For a complicated problem, it should not be expected that someone will read through all the “scratch work”.
  - lucumo 4y ago
    > For a complicated problem, it should not be expected that someone will read through all the “scratch work”. Do people really read through the changelog commit by commit? What's gained by that? I don't read through it at all. I zoom into a point that I need to know more about. I have information (bug report, runtime behaviour on other data) that allows me to zoom into a specific part. The information I have is from the committer's future. It's highly unlikely that the details needed are in the summary that they wrote.