5 ms·

> since the commit chain can be cleaned up later. This seems to be one of the major divisions in SCM users, some see it as a clean up for seeing a understandab

> since the commit chain can be cleaned up later. This seems to be one of the major divisions in SCM users, some see it as a clean up for seeing a understandable 'history', others see it as a falsification.

arxanas 4y ago
For example, Git is somewhat ambivalent on the topic, but Fossil SCM is notably very much against rebasing/rewriting history.
avgcorrection 4y ago
If you made one commit after this sequence of events 1. Worked 2. Grabbed a coffee 3. Worked again You are falsifying history. One commit or more per butt-in-seat mini session.[1] Anything else is borderline fraudulent. [1] Or per balls-of-feet in front of your standing desk, if that is how you roll.
- rileymat2 4y ago
  I'd imagine the human psychology of this debate is quite a bit more complicated.
- MereInterest 4y ago
  Falsifying history isn't wrong in itself. Falsifying a shared history is, because it breaks other copies of the repo. So long as a branch exists only in a single repo, then the history of that branch can be rewritten without issue. But a shared branch should never be rewritten, because you'd need to copy the alterations into all copies of the repo. I take issue with tools that prioritize rebasing, because they usually make this distinction between rebasing a local branch and rebasing a shared branch. For example, GitHub's "Squash and Merge" or "Rebase and Merge" options break the shared history between the remote copy of the repo and my local copy. After such an operation, I cannot merge from main into my development branch, and must instead rebase my development branch onto main.
  - atq2119 4y ago
    To be fair, once you're developing on a project with enough commits/day, you no longer have a real choice if you want an overall linear history. You will have to cherry-pick to main somehow. Some people want to rather merge instead, but in my experience few people have the discipline to develop in large enough PR granularity to make the resulting merge commits meaningful and not polluting history while also keeping the non-merge commits meaningful by doing rebases while the change is still in review.
- charcircuit 4y ago
  I disagree. Every commit should be an atomic change that doesn't break the build including both compilation and it running properly. Doing what you are suggesting makes bisects near impossible, wastes extra time in code review, and wastes the time of people looking at the history because they have to comb through half baked ideas which they do not know if they actually work or were tested.
  - avgcorrection 4y ago
    You’ll be happy to hear that I wasn’t being serious.
- thayne 4y ago
  I can't tell if this is sarcastic or not.
  - avgcorrection 4y ago
    Sarcastic. :) I dislike the “never change history” attitude. One is always curating history by deciding when to commit instead of dumping the whole undo tree.
deleted 4y ago
[deleted]
lucumo 4y ago
> some see it as a clean up for seeing a understandable 'history', others see it as a falsification. I don't see it as a falsification. I see it as making the history less understandable. Having a track of what happened, can help in understanding what was intended. Code archeology regularly helps me understand Chesterton's fence. Programmers are human. They make mistakes. The thing is not perfect at the time of squashing. When the inevitable issue crops up in production, I really want all the information I can get. If you start cleaning stuff up, not only do you deny me information about how the code evolved, you also introduce another point at which a flawed understanding can mislead those that come after you.
- pydry 4y ago
  So rather than a small mini essay written after a squash on one commit you'd rather get 10,000 "work in progress" and "oops" and "lint fixes"?
  - 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.
        4y ago
goku12 4y ago
I maintain both branches - a WIP branch and a final rebased result. I agree with the age old concept that each commit on the master should be a full self-sufficient feature. I also like to keep the messy WIP for reference. How does the 'falsification' argument apply here?

arxanas 4y ago

For example, Git is somewhat ambivalent on the topic, but Fossil SCM is notably very much against rebasing/rewriting history.

avgcorrection 4y ago

If you made one commit after this sequence of events 1. Worked 2. Grabbed a coffee 3. Worked again You are falsifying history. One commit or more per butt-in-seat mini session.[1] Anything else is borderline fraudulent. [1] Or per balls-of-feet in front of your standing desk, if that is how you roll.

rileymat2 4y ago
I'd imagine the human psychology of this debate is quite a bit more complicated.
MereInterest 4y ago
Falsifying history isn't wrong in itself. Falsifying a shared history is, because it breaks other copies of the repo. So long as a branch exists only in a single repo, then the history of that branch can be rewritten without issue. But a shared branch should never be rewritten, because you'd need to copy the alterations into all copies of the repo. I take issue with tools that prioritize rebasing, because they usually make this distinction between rebasing a local branch and rebasing a shared branch. For example, GitHub's "Squash and Merge" or "Rebase and Merge" options break the shared history between the remote copy of the repo and my local copy. After such an operation, I cannot merge from main into my development branch, and must instead rebase my development branch onto main.
- atq2119 4y ago
  To be fair, once you're developing on a project with enough commits/day, you no longer have a real choice if you want an overall linear history. You will have to cherry-pick to main somehow. Some people want to rather merge instead, but in my experience few people have the discipline to develop in large enough PR granularity to make the resulting merge commits meaningful and not polluting history while also keeping the non-merge commits meaningful by doing rebases while the change is still in review.
charcircuit 4y ago
I disagree. Every commit should be an atomic change that doesn't break the build including both compilation and it running properly. Doing what you are suggesting makes bisects near impossible, wastes extra time in code review, and wastes the time of people looking at the history because they have to comb through half baked ideas which they do not know if they actually work or were tested.
- avgcorrection 4y ago
  You’ll be happy to hear that I wasn’t being serious.
thayne 4y ago
I can't tell if this is sarcastic or not.
- avgcorrection 4y ago
  Sarcastic. :) I dislike the “never change history” attitude. One is always curating history by deciding when to commit instead of dumping the whole undo tree.

deleted 4y ago

[deleted]

lucumo 4y ago

> some see it as a clean up for seeing a understandable 'history', others see it as a falsification. I don't see it as a falsification. I see it as making the history less understandable. Having a track of what happened, can help in understanding what was intended. Code archeology regularly helps me understand Chesterton's fence. Programmers are human. They make mistakes. The thing is not perfect at the time of squashing. When the inevitable issue crops up in production, I really want all the information I can get. If you start cleaning stuff up, not only do you deny me information about how the code evolved, you also introduce another point at which a flawed understanding can mislead those that come after you.

pydry 4y ago
So rather than a small mini essay written after a squash on one commit you'd rather get 10,000 "work in progress" and "oops" and "lint fixes"?
- 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.
      - 4y ago

goku12 4y ago

I maintain both branches - a WIP branch and a final rebased result. I agree with the age old concept that each commit on the master should be a full self-sufficient feature. I also like to keep the messy WIP for reference. How does the 'falsification' argument apply here?