4 ms·

I don't understand why people equate rebase with lying. I work on a team of 12 devs, and pre rebase workflow, gitk sort of looked like a rainbow due to it showi

I don't understand why people equate rebase with lying. I work on a team of 12 devs, and pre rebase workflow, gitk sort of looked like a rainbow due to it showing the actual interactions of each developers branch at the chronological time it happened. It was so complex that git bisect often couldn't find bad commits unless you used it a specific way. Basically it made the history next to useless. Post rebase, we see branch work serially, which makes it easy to find a bad commit, and obvious to see the transformations of the main branch of code. I think people who complain about this fall into one of three camps: 1 - Are not using a topic branch workflow, and don't understand the hell that wreaks in history 2 - Are doing fast forward merges to merge branches back into the mainline, which makes it hard to see the points that development finished and the merge actually happened. 3 - Are rebasing long lived branches It is just such a common complaint, and I have yet to hear of any down side that actually makes sense to me as someone who has a fair understanding of git

seclorum 15y ago
>It is just such a common complaint, and I have yet to hear of any down side that actually makes sense to me as someone who has a fair understanding of git Probably because gaining a fair understanding of git is damned hard. Why you want to do things, and what these actions are actually for is not clear from the topology of the terms that git uses to describe these actions.
- mattbriggs 15y ago
  Fair enough, git does have a hellish interface. That is a great complaint, and I totally agree with it. The "zomg history editing!" thing just doesn't seem to die though, even though git been out for quite awhile now, and has become quite popular
  - seclorum 15y ago
    I think complaints about history editing have some validity - as a team leader, I definitely do not want the history of my project, warts and all, to be editable by junior members attempting to hide mistakes/flaws in the production flow. This leads to cacophony when time comes to figure out why things went wrong, if they do, somewhere in the past.
    - rlpb 15y ago
      This is not what rebase is for. As a team leader, nobody can rewrite the history of your project but you.

seclorum 15y ago

>It is just such a common complaint, and I have yet to hear of any down side that actually makes sense to me as someone who has a fair understanding of git Probably because gaining a fair understanding of git is damned hard. Why you want to do things, and what these actions are actually for is not clear from the topology of the terms that git uses to describe these actions.

mattbriggs 15y ago
Fair enough, git does have a hellish interface. That is a great complaint, and I totally agree with it. The "zomg history editing!" thing just doesn't seem to die though, even though git been out for quite awhile now, and has become quite popular
- seclorum 15y ago
  I think complaints about history editing have some validity - as a team leader, I definitely do not want the history of my project, warts and all, to be editable by junior members attempting to hide mistakes/flaws in the production flow. This leads to cacophony when time comes to figure out why things went wrong, if they do, somewhere in the past.
  - rlpb 15y ago
    This is not what rebase is for. As a team leader, nobody can rewrite the history of your project but you.