Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.


Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago?

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?


Basically equivalent to that. This was about a decade ago.

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.


So (sorry for picking on this scab) there became 4 branches each of which for the team concerned was the next beautiful branch and then say each week a team woukd merge into master and everyone woukd rebase but fuck that up once and now the beautiful branch team B is working on is out of step with the real master ... oh god.

Yeah that would leave a mark.


It looks like you’re talking about rewriting history that has already been shared. Pretty much everyone agrees that is a bad idea. It even has a prominent warning in the git book.

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.


But that make no sense, as the second someone pulls from that branch it would be noticed.


Wasn’t `git reflog` viable?


How do you find the right commit from a month ago to reflog to?

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: