Hi Paul, On Sat, 12 Mar 2016, Paul Tan wrote:
> Since 1b1dce4 (Teach rebase an interactive mode, 2007-06-25), git-rebase > supports an interactive mode when passed the -i switch. > > In interactive mode, git-rebase allows users to edit the list of patches > (using the user's GIT_SEQUENCE_EDITOR), so that the user can reorder, > edit and delete patches. > > Re-implement a skeletal version of the above feature by introducing a > rebase-interactive backend for our builtin-rebase. This skeletal > implementation is only able to pick and re-order commits. > > Signed-off-by: Paul Tan <pyoka...@gmail.com> It is a pity that both of us worked on overlapping projects in stealth mode. Inevitably, some of the work is now wasted :-( Not all is lost, though. Much of the code can be salvaged, although I really want to reiterate that an all-or-nothing conversion of the rebase command is not going to fly. For several reasons: it would be rather disruptive, huge and hard to review. It would not let anybody else work on that huge task. And you're prone to fall behind due to Git's source code being in constant flux (including the rebase bits). There is another, really important reason: if you package the conversion into small, neat bundles, it is much easier to avoid too narrow a focus that would tuck perfectly useful functions away in a location where it cannot be reused and where it is likely to be missed by other developers who need the same, or similar functionality (point in case: has_uncommitted_changes()). And we know that this happened in the past, and sometimes resulted in near-duplicated code, hence Karthik's Herculean, still ongoing work. Lastly, I need to point out that the conversion of rebase into a builtin is not the end game, it is the game's opening. I could imagine that other Git oldtimers are perfectly happy with the state of the rebase family of commands. I am not. The user interface is klunky, some parts are designed wrong (--preserve-merges, I am looking at you!), the *name* is completely unintuitive, for crying out loud! Just to name a *few* things, there is much more. I worked around the limitations of the --preserve-merges feature (yeah, blame me...) by inventing the "Garden Shears" [*1*] that can re-plant an entire thicket of topic branches on top of a moving upstream branch. It is similar in spirit to Junio's custom tools that recreate his 'pu' branch over and over again, but uses the interactive rebase as work horse. The shears can also be used to fix up commits in the middle of a thicket of branches, which is why I wrote the shears script in the first place. The fact that the interactive rebase does not do the job with which pretty much every project maintainer is faced points out two things: interactive rebase needs to learn new tricks, and we need plumbing to do interactive rebase's bidding (so that we/others can build better UIs, hopefully with much better names, too). I already know pretty well how I want to implement the shears as a new mode of the interactive rebase, once I finished teaching the sequencer how to process rebase -i's edit scripts (which somebody decided to name "instruction sheets" in the sequencer, to add confusion to poor naming). All of this let's me think that there is just too much to do for a single developer, and therefore whatever needs to be done must be done in a way that allows more than a single person to complete the whole shebang, or at least their part of it. So you see, there was a much larger master plan behind my recommendation to go the rebase--helper route. As to my current state: Junio put me into quite a fix (without knowing it) by releasing 2.7.3 just after I took off for an extended offline weekend, and now I am scrambling because a change in MSYS2's runtime (actually, probably more like: an update of the GCC that is used to compile the runtime, that now causes a regression) is keeping me away from my work on the interactive rebase. Even so, I am pretty far along; There are only three major things left to do: 1) fix fixups/squashes with fast-forwarding picks, 2) implement 'reword', 3) display the progress. And of course 4) clean up the fallout. ;-) At this point, I'd rather finish this myself than falling prey to Brooks' Law. I also have to admit that I would love to give you a project over the summer whose logical children are exciting enough to dabble with even during the winter. And somehow I do not see that excitement in the boring conversion from shell to C (even if its outcome is well-needed). Ciao, Dscho Footnote *1*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
