7 ms·
No it isn't. Are you thinking about filter-branch?
by marble-drink 7y ago
No it isn't. Are you thinking about filter-branch?
- Avamander 7y agoI 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.
- packetlost 7y ago... 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 https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...
- Avamander 7y agoYes, autocorrect changed it. So last ten commits isn't slow but I literally asked about entire git history.
- falsedan 7y agoWhy would you rebase an entire git history? No one is arguing for that.
- Avamander 7y agoI... 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.
- icebraining 7y agoYour 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.