3 ms·

> Git strives to record what the development of a project should have looked like had there been no mistakes. Hmm. I think I disagree. One can clean the commit

> Git strives to record what the development of a project should have looked like had there been no mistakes. Hmm. I think I disagree. One can clean the commit history to look like that, but it's optional. You can merge all of your messy starts and restarts right into master if you want. Easier to do, in fact.

deleted 5y ago
[deleted]
wildmanx 5y ago
But then you are on your own, tooling-wise.
daniellarusso 5y ago
One of the repos I interact with, the team rebases all their local branch commits to master. It is very difficult to read the commit history and get a sense of anything except Jira issue codes. One needs to look at the individual files and read the code to understand what the commit was for.
- nerdponx 5y ago
  This is why the best Git workflows IMO involve rebasing and squashing the branch down to a couple of well-defined "logical commits", then merging that (with --no-ff of course) into master/main/trunk. This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.
- jacoblambda 5y ago
  I think that's a consequence of rebasing. If you just merge instead, you can use the branching/merging to get a sense of complete features/changes.
  - nerdponx 5y ago
    Right, I think there's a bit of subtlety lost here. "Squash and merge to trunk" is very different from "rebase on every pull on a feature branch" which is very different from "rebase and fixup/squash before merging to trunk" etc. On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much. In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message. Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.
    - jacoblambda 5y ago
      Yep I agree. I tend to rebase my feature branches into a sensible history and then merge that in as I find that leaves the cleanest history that is still easily navigable. I wish this workflow was better supported but since it isn't most people just default to squash and merge or rebase and merge.
elviejo 5y ago
except the community in git, specially GitHub, is in favor of rewriting history so if you commit the messy history you are on your own. the community in fossil is in favor of accurately recording history.
EvanDotPro 5y ago
I've always advocated maintaining true, "messy" history (in git) amongst my teams. I know it's controversial, but anecdotally, verbose history has helped me understand the nuance of otherwise opaque changes and decisions so many times that I can't help but cringe when a bunch of context is lost to squashing for the sake of a "clean" history. Many of the technical arguments for squashing tend to be things that can be mitigated by simply traversing merge commits only.
- mook 5y ago
  Wouldn't _not_ squashing be sufficient, rather than having to keep all of the messy commits? That is, would you be satisfied with modifying history such that the commits are logically separate, even if it's not how the code actually evolved? I don't understand the desire to squash every PR into one commit each either…
  - EvanDotPro 5y ago
    Sure, I'm not a total purist about it. What's important to me is maintaining the logical progression of a change, even if it includes some dead ends, non starters, or mistakes. If you want to amend commits for a typo, code style fix, or otherwise inconsequential change that doesn't add any useful context for future developers, by all means go for it.
- ajb 5y ago
  TBH That's because squashing is the quick and dirty option. If I have time, I prefer to rebase and organise the changes into a number of commits each addressing one concern. The only thing that gets removed is bugs and typos which I were introduced on that feature branch, and then fixed again. No need for those to go upstream - it would just add noise.

deleted 5y ago

[deleted]

wildmanx 5y ago

But then you are on your own, tooling-wise.

daniellarusso 5y ago

One of the repos I interact with, the team rebases all their local branch commits to master. It is very difficult to read the commit history and get a sense of anything except Jira issue codes. One needs to look at the individual files and read the code to understand what the commit was for.

nerdponx 5y ago
This is why the best Git workflows IMO involve rebasing and squashing the branch down to a couple of well-defined "logical commits", then merging that (with --no-ff of course) into master/main/trunk. This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.
jacoblambda 5y ago
I think that's a consequence of rebasing. If you just merge instead, you can use the branching/merging to get a sense of complete features/changes.
- nerdponx 5y ago
  Right, I think there's a bit of subtlety lost here. "Squash and merge to trunk" is very different from "rebase on every pull on a feature branch" which is very different from "rebase and fixup/squash before merging to trunk" etc. On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much. In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message. Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.
  - jacoblambda 5y ago
    Yep I agree. I tend to rebase my feature branches into a sensible history and then merge that in as I find that leaves the cleanest history that is still easily navigable. I wish this workflow was better supported but since it isn't most people just default to squash and merge or rebase and merge.

elviejo 5y ago

except the community in git, specially GitHub, is in favor of rewriting history so if you commit the messy history you are on your own. the community in fossil is in favor of accurately recording history.

EvanDotPro 5y ago

I've always advocated maintaining true, "messy" history (in git) amongst my teams. I know it's controversial, but anecdotally, verbose history has helped me understand the nuance of otherwise opaque changes and decisions so many times that I can't help but cringe when a bunch of context is lost to squashing for the sake of a "clean" history. Many of the technical arguments for squashing tend to be things that can be mitigated by simply traversing merge commits only.

mook 5y ago
Wouldn't _not_ squashing be sufficient, rather than having to keep all of the messy commits? That is, would you be satisfied with modifying history such that the commits are logically separate, even if it's not how the code actually evolved? I don't understand the desire to squash every PR into one commit each either…
- EvanDotPro 5y ago
  Sure, I'm not a total purist about it. What's important to me is maintaining the logical progression of a change, even if it includes some dead ends, non starters, or mistakes. If you want to amend commits for a typo, code style fix, or otherwise inconsequential change that doesn't add any useful context for future developers, by all means go for it.
ajb 5y ago
TBH That's because squashing is the quick and dirty option. If I have time, I prefer to rebase and organise the changes into a number of commits each addressing one concern. The only thing that gets removed is bugs and typos which I were introduced on that feature branch, and then fixed again. No need for those to go upstream - it would just add noise.