About 11 years ago I started writing “wiggle”. I have finally released version 1.0.
Wiggle is a tool for applying patches with conflicts. I do quite a bit of applying patches to a release different to the one they were created for. This often works, and often fails completely so that the task must be done completely by hand.
But sometimes – and often enough to be worth automating – the ‘patch’ program cannot apply the patch successfully, but the reason is due to small differences that can automatically be detected and ignored. This is where “wiggle” comes in. It looks at the patch word-by-word, and wiggles that patch in if at all possible.
I got wiggle to the point where this basic functionality worked a long time ago. But I found it less that satisfactory. Often “patch” would fail and “wiggle” would succeed and I would want to know why. And “wiggle” didn’t really tell me why.
This lead me on the path of writing “browse” mode for wiggle. This allows me to look at the merge and see the different bits highlighted so I can see what confused “patch” and decide if it was reasonable for wiggle to silently fix it.
I then found that I wanted to be able to “fix” things up while in browse mode. Some little conflicts that wiggle cannot fix automatically still have simple fixes that I could determine based on my understanding of the code. Figuring out how to do that was not easy. I knew in general terms what I wanted to achieve, but had no real idea of the concrete steps.
So much of the last few year, when I have had the opportunity, has seen me improving various aspects of the browser, making it easy to move around and handling various corner cases and getting enough ground work in place that I could usefully experiment with editing. Only recently have I taught wiggle some very basic commands for editing. I don’t really know if they are enough, but they will do for now.
There are basically 3 things you can do.
- You can mark a conflict or change and “unchanged”. This effectively ignores part of the patch and leaves the original as it is.
- You can mark a conflict or ‘unmatched’ as ‘changed’. This effectively discards the original and keeps what was in the patch, even though it might not have lined up properly.
- After the above has proven to be insufficient, you can open the merge result in an editor and fix the rest up by hand.
Obviously the last possibility has always been an option, though not directly from wiggle. This is how I most often work with failed patches. I apply “wiggle” then look at the results in an editor. Allowing the editor to be invoked directly from wiggle should streamline the process a little. Allowing some simple changes before hand should make it even better. Only time will tell.
So wiggle 1.0 is out there, in git://neil.brown.name/wiggle/ or http://neil.brown.name/wiggle/. If you want to know more, you can see the talk I recently have at LCA2013.
