Hacker News Reader

Comment by orra | Hacker News Reader

git rebase -i (interactive rebase) is, however, to kill for.

I 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.

Some 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.

> 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

> 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'.

> > 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

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.

If you read my post again, you'll see that I already mentioned rerere :)

And 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)

Reply on news.ycombinator.com