Git cherry-pick and revert use 3-way merge

Re:Git cherry-pick and revert use 3-way merge by jkubicek on Friday November 10, 2023 @04:10PM (#38224590)

How do you correct the following commit history?

    1. New function & unit tests
    2. Switch existing code to use new function
    3. Whoops, new function broke some existing code
    4. I guess I need to fix tests too
    5. Spelin mistakes

There's at least three ways to clean this up:

First, you could maybe do an interactive rebase, move commits 3-5 up and squash into commit 1. Maybe easy, or maybe you hose yourself and break everything.

Second, just squash it into a single commit. No possible way to screw this up, works every time.

Third, do a `merge --no-commit`, commit your changes and your tests, commit the changes to the existing library to use your new method. Easy and straightforward and keeps the two change separate if that's something you're into.

Of the three choices, rebasing is the worst!

[ Parent | on HN ]

Re:Git cherry-pick and revert use 3-way merge by yencabulator on Friday November 10, 2023 @05:36PM (#38225506)

    1. git commit lib/bar.x
    2. git commit foo.x
    3. git commit --fixup sha_of_1
    4. git commit --fixup sha_of_1
    5. git commit --fixup whichever_is_appropriate
    n. git rebase -i where_ever_you_branched_off

You call git rebase "worst" purely because you don't currently see the value in granular commit history. If and when you do, git rebase is just the tool for the job.

`git merge --no-commit` only works for trivial things, real world is a lot messier than that. But perhaps you haven't needed to deal with the complex changes. For an idea of what complex changes look like, skim some linux kernel VFS or MM refactoring patch sets.

[ Parent | on HN ]