> I used to work at a company where someone (we never figured out who)
Wouldn't this be trivially solvable by git bisecting your deploy branch?
Wouldn't this be trivially solvable by git bisecting your deploy branch?
I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB".
or am I missing something?
We had 4 teams, each released on a schedule. Each team had a branch. When a team released, it was merged from master, then each team pulled. The person who did the pull would change, and it was often a rebase.
So my team released, some other team rebased badly. There would be no sign of problems for us until after they released. But since 2 teams generally released at once, and people didn't remember who actually did the merge a few weeks earlier, it was hard to figure out who was actually messing up. (I had suspicions, but no proof.)
I've seen rebase used appropriately since. But that disaster left scar tissue.
Yeah that would leave a mark.
What others here, including myself, are advocating is rewriting your own history before you share it, which makes a very different set of trade-offs.
How do you determine which combination of changes are yours, and not accidentally undo changes that other developers made in the last month?
Could git reflog have helped? Maybe sometimes. If we had the foresight to have saved the right commits from the past, sure. I think we did start saving old branches just in case it happened again, but then we had to sort through a month of changes to figure out what to keep, what to change, and what conflicts there might be.
Remember, the person screwing up didn't know he screwed up. And the person trying to fix it is doing so a long time after the fact. It was a disaster.