loading...

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

Collapse
tiguchi profile image
Thomas Iguchi

If I'm understanding you correctly, this seems to be pretty much what Phabricator does with Differential.

By default Phabricator squash merges accepted PRs as single commits into the mainline development branch, so "one idea" = one ticket = one commit, which makes the Git history really easy to understand. No funny "Fix spec?" in between commits there (sorry Ben).

But the commit history that led to that accepted change is preserved in Differential revisions, so it's possible to see the whole discussion and in between changes that led to the final commit

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