git/sequencer.h, branch v2.15.2

rebase -i: rearrange fixup/squash lines using the rebase--helper

2017-07-27T22:35:06Z

This operation has quadratic complexity, which is especially painful on Windows, where shell scripts are *already* slow (mainly due to the overhead of the POSIX emulation layer). Let's reimplement this with linear complexity (using a hash map to match the commits' subject lines) for the common case; Sadly, the fixup/squash feature's design neglected performance considerations, allowing arbitrary prefixes (read: `fixup! hell` will match the commit subject `hello world`), which means that we are stuck with quadratic performance in the worst case. The reimplemented logic also happens to fix a bug where commented-out lines (representing empty patches) were dropped by the previous code. While at it, clarify how the fixup/squash feature works in `git rebase -i`'s man page. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

rebase -i: skip unnecessary picks using the rebase--helper

2017-07-27T22:35:05Z

In particular on Windows, where shell scripts are even more expensive than on MacOSX or Linux, it makes sense to move a loop that forks Git at least once for every line in the todo list into a builtin. Note: The original code did not try to skip unnecessary picks of root commits but punts instead (probably --root was not considered common enough of a use case to bother optimizing). We do the same, for now. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

rebase -i: check for missing commits in the rebase--helper

2017-07-27T22:35:05Z

rebase -i: also expand/collapse the SHA-1s via the rebase--helper

2017-07-27T22:35:05Z

This is crucial to improve performance on Windows, as the speed is now mostly dominated by the SHA-1 transformation (because it spawns a new rev-parse process for *every* line, and spawning processes is pretty slow from Git for Windows' MSYS2 Bash). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

rebase -i: generate the script via rebase--helper

2017-07-27T22:35:05Z

The first step of an interactive rebase is to generate the so-called "todo script", to be stored in the state directory as "git-rebase-todo" and to be edited by the user. Originally, we adjusted the output of `git log ` using a simple sed script. Over the course of the years, the code became more complicated. We now use shell scripting to edit the output of `git log` conditionally, depending whether to keep "empty" commits (i.e. commits that do not change any files). On platforms where shell scripting is not native, this can be a serious drag. And it opens the door for incompatibilities between platforms when it comes to shell scripting or to Unix-y commands. Let's just re-implement the todo script generation in plain C, using the revision machinery directly. This is substantially faster, improving the speed relative to the shell script version of the interactive rebase from 2x to 3x on Windows. Note that the rearrange_squash() function in git-rebase--interactive relied on the fact that we set the "format" variable to the config setting rebase.instructionFormat. Relying on a side effect like this is no good, hence we explicitly perform that assignment (possibly again) in rearrange_squash(). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sequencer (rebase -i): learn about the 'verbose' mode

2017-01-09T22:57:29Z

When calling `git rebase -i -v`, the user wants to see some statistics after the commits were rebased. Let's show some. The strbuf we use to perform that task will be used for other things in subsequent commits, hence it is declared and initialized in a wider scope than strictly needed here. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sequencer: support a new action: 'interactive rebase'

2017-01-09T22:57:29Z

This patch introduces a new action for the sequencer. It really does not do a whole lot of its own right now, but lays the ground work for patches to come. The intention, of course, is to finally make the sequencer the work horse of the interactive rebase (the original idea behind the "sequencer" concept). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sequencer: get rid of the subcommand field

2016-10-21T16:32:34Z

The subcommands are used exactly once, at the very beginning of sequencer_pick_revisions(), to determine what to do. This is an unnecessary level of indirection: we can simply call the correct function to begin with. So let's do that. While at it, ensure that the subcommands return an error code so that they do not have to die() all over the place (bad practice for library functions...). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sequencer: plug memory leaks for the option values

2016-10-21T16:31:53Z

The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves like a one-shot command when it reads its configuration: memory is allocated and released only when the command exits. This is kind of okay for git-cherry-pick, which *is* a one-shot command. All the work to make the sequencer its work horse was done to allow using the functionality as a library function, though, including proper clean-up after use. To remedy that, take custody of the option values in question, allocating and duping literal constants as needed and freeing them at end. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sequencer: use memoized sequencer directory path

2016-10-17T18:52:23Z

Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano