loading...

Discussion on: Is git commit --amend truly *important*?

Collapse
kallmanation profile image
Nathan Kallman

It's similar; that appears to be a fancy version of github's squash and merge (if I'm reading correctly).

What I want is an even beefier version where I could have two distinct commits on the mainline branch (or more) based on some magical input from me on how to squish the original history together.


Consider building an AB test for new functionality. I know one of these code paths will be deleted after the test (either A or B). It would be useful if I could do that with only git revert instead of re-digging through the code...

If I create a first commit that implements the B feature as though it simply replaces the A feature then add a second commit that adds the A feature back in according to whatever testing switch is needed. Then after the test concludes I can simply git revert <second-commit> to choose the B variant or follow that with a git revert <first-commit> to choose the original A variant.

The only way to get commits like that is by doing it perfectly from the beginning or editing history with amends, squashes, and fixups...

Thread Thread
tiguchi profile image
Thomas Iguchi

Got it, that's an interesting scenario. Especially when A-B testing is done in production.

I guess that problem with reverting a throwaway feature commit could be prevented by maintaining two feature branches for each tested feature, and build them so they maybe run in separate production environments. And a load balancer or some other kind of front end would decide where a user ends up (test A or B)

That would make sure that those distinct features don't have to be added to the same mainline dev branch, and in the end you can simply abandon one branch and merge in the other