Hacker News new | ask | show | jobs
by Glyptodon 3 days ago
My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)
3 comments
hetman 3 days ago
If all I'm doing with git rebase is reorganising my commits, and I have to deal with conflicts, after I'm done, I always git diff my pre-rebase head with post rebase head commit hash. I can quickly see I've messed something up if the diff isn't empty. For more complex tasks it's best to leave the rearranging until last, but where not possible, the diff is still pretty useful to double check my work.
link
seba_dos1 3 days ago
range-diff can be useful for that too.
link
seba_dos1 3 days ago
Setting:

    merge.conflictStyle = zdiff3
made most of my fears regarding conflict resolution go away, as it right away gives me the stuff that I used to look for manually to understand the context of the conflict, which was probably the most error prone part of the process.
link
mike_hock 2 days ago
Like all git operations that destroy history, it's a bit less scary than rm or unlink, because you can undo obvious fuckups using the reflog. Non-obvious fuckups will (by Murphy's law) only be detected long after the reflog has been GC'd, so it still risks losing work.

Git was written with Linux in mind, where curating a clean commit history is more important than the code itself and warrants the extra hassle.

An actually usable rebase would probably require something like a meta history. But then the meta history would accumulate fixup "commits" and typos in commit messages so the OCD people will want to change that and we're back to square one. In practice, the two times per decade it actually makes business sense to dig through the history to find when a bug was introduced instead of just writing the 5-line fix, you can live with a couple of imperfect commits and merges.

link