4 ms·

I have never understood the benefit of hiding away the actual history. Many people i know find rebasing to be superior because you have this pretty history, but

by domano 5y ago

I have never understood the benefit of hiding away the actual history. Many people i know find rebasing to be superior because you have this pretty history, but i actually love having the ability to understand what happended when exactly as it happened in reality.

formerly_proven 5y ago
"No broken commits" is one, "nobody cares how often you merged master into your feature branch" is another. Most of the real reasons revolve around making a bisect quicker and easier.
- kerblang 5y ago
  If it helps any, I usually squash-merge my final output into sparkling, concise commits with nice messages (my original branch usually has "x" for every commit message). And yes I have a dedicated script for squash-merging too...
- patrickthebold 5y ago
  My preference is to disallow/disable fast-forward (and squash) merges to master, and then use --first-parent when you want the clean non-broken easily bisectable history, which is most of the time, but the full messy history is still there. I actually don't care so much about seeing the messy history, but its annoying when everyone on a team is always rebasing there branches and force pushing them. I've definitely been at places where one team member is waiting on another to merge their code to master so they can start working. Of course, rebase all you want locally before you push.
  - Buttons840 5y ago
    Try not pulling other team members branches. What I mean by that is instead of having your own branch HEAD/tag (whatever the term?) for their branch, do `git checkout origin/their-branch` when checking out their branch. Git will complain about a detached HEAD, that's OK. Then later when they rebase and force push, just do the same thing again, and you never have to worry about making sure your own local branch for their branch is in sync.
vendiddy 5y ago
I agree here. It feels like the popularity of git has lead us to believe that you either have to choose a clean history or the real history. But I imagine there exists a design for a source control system where you can preserve history and also provide a clean interpretation of that history. For example, why does rebase have to be a destructive operation?
sangnoir 5y ago
This depends on mindset: what do you consider the primary building block for a changeset - the changes, as made by the developer in chronological order or changes that are related by logic, despite the time (and order) in which they were made. I favor the latter approach - developers in the future will have no use in knowing the different approaches I attempted before coming to the actual solution - that is noise. What they should care about (IMO) are logical commits with related changes. Additionally, "preserving detailed history" makes cherry-picking fixes across multiple release branches a royal pain: not everyone has the luxury of having on single, ever-green release branch. So having a feature/fix in a single, self-contained commit that hides away the actual history is a good thing in this scenario (with the added bonus of not running into fluff/half-cooked commits when running git bisect)
- domano 5y ago
  I usually squash my commits before merging, i think that makes things easier while still keeping the chronological view intact
ivanche 5y ago
It's not about history. It's about correctness. Let's say there's a master branch at commit M1. You branch off of it. You develop your feature branch. In the meantime, master is at commit M26. Now on your feature branch all your tests pass, maybe even there's no merge conflict with the current master. But! Master's behaviour changed and you have no idea about it, and no idea whether it affects your branch. You merge feature to branch and kaboom! Frequent rebasing protects you from this.
- domano 5y ago
  You could also frequently merge master into your branch and squash at the end.
  - ivanche 5y ago
    But squashing changes chronological view, right? Either you want "real" history or not. If you're already willing to do that then with the same amount of work you get cleaner history with rebasing, i.e. no intertwined branches.

by domano 5y ago

formerly_proven 5y ago

"No broken commits" is one, "nobody cares how often you merged master into your feature branch" is another. Most of the real reasons revolve around making a bisect quicker and easier.

kerblang 5y ago
If it helps any, I usually squash-merge my final output into sparkling, concise commits with nice messages (my original branch usually has "x" for every commit message). And yes I have a dedicated script for squash-merging too...
patrickthebold 5y ago
My preference is to disallow/disable fast-forward (and squash) merges to master, and then use --first-parent when you want the clean non-broken easily bisectable history, which is most of the time, but the full messy history is still there. I actually don't care so much about seeing the messy history, but its annoying when everyone on a team is always rebasing there branches and force pushing them. I've definitely been at places where one team member is waiting on another to merge their code to master so they can start working. Of course, rebase all you want locally before you push.
- Buttons840 5y ago
  Try not pulling other team members branches. What I mean by that is instead of having your own branch HEAD/tag (whatever the term?) for their branch, do `git checkout origin/their-branch` when checking out their branch. Git will complain about a detached HEAD, that's OK. Then later when they rebase and force push, just do the same thing again, and you never have to worry about making sure your own local branch for their branch is in sync.

vendiddy 5y ago

I agree here. It feels like the popularity of git has lead us to believe that you either have to choose a clean history or the real history. But I imagine there exists a design for a source control system where you can preserve history and also provide a clean interpretation of that history. For example, why does rebase have to be a destructive operation?

sangnoir 5y ago

This depends on mindset: what do you consider the primary building block for a changeset - the changes, as made by the developer in chronological order or changes that are related by logic, despite the time (and order) in which they were made. I favor the latter approach - developers in the future will have no use in knowing the different approaches I attempted before coming to the actual solution - that is noise. What they should care about (IMO) are logical commits with related changes. Additionally, "preserving detailed history" makes cherry-picking fixes across multiple release branches a royal pain: not everyone has the luxury of having on single, ever-green release branch. So having a feature/fix in a single, self-contained commit that hides away the actual history is a good thing in this scenario (with the added bonus of not running into fluff/half-cooked commits when running git bisect)

domano 5y ago
I usually squash my commits before merging, i think that makes things easier while still keeping the chronological view intact

ivanche 5y ago

It's not about history. It's about correctness. Let's say there's a master branch at commit M1. You branch off of it. You develop your feature branch. In the meantime, master is at commit M26. Now on your feature branch all your tests pass, maybe even there's no merge conflict with the current master. But! Master's behaviour changed and you have no idea about it, and no idea whether it affects your branch. You merge feature to branch and kaboom! Frequent rebasing protects you from this.

domano 5y ago
You could also frequently merge master into your branch and squash at the end.
- ivanche 5y ago
  But squashing changes chronological view, right? Either you want "real" history or not. If you're already willing to do that then with the same amount of work you get cleaner history with rebasing, i.e. no intertwined branches.