Hacker News Reader

Comment by marble-drink | Hacker News Reader

No it isn't. Are you thinking about filter-branch?

I am not. Manually issuing rebranch is too slow for any git histories over a few hundred. You'd then also have to find which commits you want to merge, merge them and so on and on. Rebranch basically works if you just want to fix one mistake in history you know you have.

... what? `rebranch` isn't a command in git? I think you mean rebase, and sure, if you were rebasing the entire history it would be slow and awful. But don't do that. Rebase at like `HEAD~10` (or whatever) to only clean up the last 10 commits. There's no performance issues or even management issues. Maybe go read the rebasing section (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...

Yes, autocorrect changed it. So last ten commits isn't slow but I literally asked about entire git history.

Why would you rebase an entire git history? No one is arguing for that.

I... like, the first comment in the thread I asked if there's a tool that could go over the entire git history of a repo and fix such issues up, rebase isn't a solution in that case because it does get slow and it requires manual work which is slow, I don't understand how people are losing the context so quickly here.

Your comment didn't say "the entire git history of a repo", and in the context of this thread, people made the reasonable assumption your were talking about a few sequential commits, as discussed regarding the edits to README on the Requests repo.

Reply on news.ycombinator.com