My current workplace has a pretty strong and widespread practice of amending (or fixups). It helps immensely for reviews of slightly more complex units of work to present it as a story; an anecdote that I often find myself doing:
Refactored animals to handle mythological creatures without edge-cases.
Added my unicorns to the code-base
I want these in one PR, because the refactor makes little sense without the context of the new unicorns, but the new unicorns would be horrifically difficult to implement without the refactor. Grouping the relevant changes (even if I had to go back and forth a few times to get each group right; nobody's perfect) makes it much easier to review each change (because the intention can be clearly seen) than going through a messy history or looking at everything at once.
I think my dream feature would be if history could be preserved but PRs could be constructed to present the history into a set of meaningful diffs for review... a dev can dream right?
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
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...
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My current workplace has a pretty strong and widespread practice of amending (or fixups). It helps immensely for reviews of slightly more complex units of work to present it as a story; an anecdote that I often find myself doing:
I want these in one PR, because the refactor makes little sense without the context of the new unicorns, but the new unicorns would be horrifically difficult to implement without the refactor. Grouping the relevant changes (even if I had to go back and forth a few times to get each group right; nobody's perfect) makes it much easier to review each change (because the intention can be clearly seen) than going through a messy history or looking at everything at once.
I think my dream feature would be if history could be preserved but PRs could be constructed to present the history into a set of meaningful diffs for review... a dev can dream right?
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
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 revertinstead 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 agit 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...
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