4 ms·
git rebase -i (interactive rebase) is, however, to kill for.
by orra 5y ago
git rebase -i (interactive rebase) is, however, to kill for.
- strictfp 5y agoI don't know, git doesn't have very good memory when doing rebases. You need to redo the same conflict resolution several times. You need rerere to get around that. Plus that it's quite hard to rewrite dates, names, or split commits into several.
- orra 5y agoSome fair points, but these things are possible. Last time I was using Mercurial—which was admittedly a long time ago—there wasn't /anything/ like fixup.
- TeeMassive 5y ago> I don't know, git doesn't have very good memory when doing rebases. https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere > Plus that it's quite hard to rewrite dates, names, or split commits into several. Read the documentation for 'rebase' and 'cherry-pick' and 'add'.
- growse 5y ago> > I don't know, git doesn't have very good memory when doing rebases. > https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere Thank you for this, looks like exactly what I need at the moment maintaining a dev branch alongside a bugfix deployed main branch and having to do lots of rebasing.
- strictfp 5y agoIf you read my post again, you'll see that I already mentioned rerere :)
- mdaniel 5y agoAnd its friend, "git rebase -i --autosq" for when you knew at commit time that you needed to fold a fix into an earlier commit, by setting the commit message as "fixup! cafebabedeadbeef" or "fixup! the old commit message" (but I have less experience with the latter form)