git-tools
git-tools copied to clipboard
cecton
RFE: try-merge -x
Promoting this tweet to a proper RFE. This is a little handwavey, and if it's too far out of scope or seems like it should be fixed some other way feel free to ignore it.
One feature I really like about git rebase is the -x option, which lets me run a script between each commit and halt the rebase at that point if it fails. This is great for verifying that the result builds at every step, or as an alternative to git bisect run for finding where my changes introduce a test failure.
try-merge looks like it only verifies that the merge succeeded in a textual sense. It would be nice if it had a similar -x feature to allow you to verify the tree's integrity in terms of being buildable or test-clean at every step. This would obviously be quite a lot slower, but in some cases that can be a price I'm willing to pay.
For instance, one project I have is reviving an old 3d driver in the Mesa project. It was deleted long long ago, so many of the project's internal APIs have changed over time. Merging the old driver's code back to current devel tip is trivial enough, but figuring out which of the resulting build failures to fix first is prohibitive; it makes more sense to pretend it was never deleted, and to work my way through internal API changes "as they happened". I had a hacky solution for this that just applied the old driver code to top-of-tree as a new commit, and then iteratively git-rebase my way forward from the old tree state just before it was deleted and cherry-pick the revival commit, try to build it, if it does decommit it and step forward in the rebase by one, etc... which needed a bunch of hand holding every time the build did fail.
-x itself sounds totally doable.
Just one detail to be sure we understand each other: do you know that try-merge starts merging from the top (most recent) and then only go back in the history to try to find the first not conflicting commit?
I... did not! My apologies, I haven't tried using it in combat yet. I was thinking it walked the history forward from old to new.
I'm wondering now if suitably clever git hooks can get me what I want. Will investigate.
It sounds very useful so I want to do it.
That would be the heuristic, correct me if I'm wrong:
- find the highest mergeable commit possible without conflict (just like
git try-merge --no-merge) - merge it temporarily
- run the
-xcommand - if it failed, "automatic bisect" until the command pass
(I did not forget about you. I was enjoying holiday :) I will do it at some point in a near future)
I want to refactor/cleanup the code. That's like my second or third attempt. It's a huge time eater. So it will be for next time again :grin: sorry!
What I say: git bisect
What I do: manually test handpicked suspicious revisions in something that mostly resembles a binary search
I saw this on twitter and I thought maybe it would be nice to allow the user to select the commit among a list that reduces over time. Maybe with a curses interface.