Quickly shell out to your editor, make a change and return to the tool. GitBash requires the use of winpty in order to work correctly, so to set the editor use:.
Windows before version 10 has serious rendering issues with saturated darker colors , such as the blue color that is entirely illegible on modern displays. While it is possible to avoid using saturated colors, a better option is to update the theme using Microsoft's ColorTool. Key bindings can be configured, see configuration for more information.
To start developing the project, you will need to install Rust , which can generally be done using rustup. This project uses cargo-make as a task runner.
To install:. If you plan to build a release package you will need pkg-config and liblzma-dev. They can be installed using apt :. An addition to the lints provided by rustc, this project uses Clippy to provide additional linting, run with:. This will run lints using stable and nightly. Star 1k. Permalink master. Branches Tags. Could not load branches. Could not load tags. Raw Blame. Open with Desktop View raw View blame.
Git Interactive Rebase Tool Native cross-platform full feature terminal based sequence editor for interactive rebase in Git 1. Set action Easily set the action to pick , squash , fixup , edit , reword and drop.
Reorder rebase list Reorder the action list with a single key press. GitBash requires the use of winpty in order to work correctly, so to set the editor use:. Windows before version 10 has serious rendering issues with saturated darker colors , such as the blue color that is entirely illegible on modern displays.
While it is possible to avoid using saturated colors, a better option is to update the theme using Microsoft's ColorTool. The tool has built-in help that can be accessed by hitting the? Key bindings can be configured, see configuration for more information. To start developing the project, you will need to install Rust , which can generally be done using rustup. It also drops commits that become empty and has no option for controlling this behavior. The merge backend keeps intentionally empty commits by default though with -i they are marked as empty in the todo list editor, or they can be dropped automatically with --no-keep-empty.
Due to the lack of accurate tree information arising from constructing fake ancestors with the limited information available in patches , directory rename detection is disabled in the apply backend. Disabled directory rename detection means that if one side of history renames a directory and the other adds new files to the old directory, then the new files will be left behind in the old directory without any warning at the time of rebasing that you may want to move these files into the new directory.
The apply backend works by creating a sequence of patches by calling format-patch internally , and then applying the patches in sequence calling am internally. Patches are composed of multiple hunks, each with line numbers, a context region, and the actual changes. The line numbers have to be taken with some fuzz, since the other side will likely have inserted or deleted lines earlier in the file.
The context region is meant to help find how to adjust the line numbers in order to apply the changes to the right lines. However, if multiple areas of the code have the same surrounding lines of context, the wrong one can be picked.
There are real-world cases where this has caused commits to be reapplied incorrectly with no conflicts reported. Setting diff.
The merge backend works with a full copy of each relevant file, insulating it from these types of problems.
Since the apply backend drops the original information about the rebased commits and their parents and instead generates new fake commits based off limited information in the generated patches , those commits cannot be identified; instead it has to fall back to a commit summary.
Also, when merge. The merge backend works with the full commits on both sides of history and thus has no such limitations. The apply backend has not traditionally called the post-commit hook, while the merge backend has. Both have called the post-checkout hook, though the merge backend has squelched its output.
Further, both backends only call the post-checkout hook with the starting point commit of the rebase, not the intermediate commits nor the final commit. In each case, the calling of these hooks was by accident of implementation rather than by design both backends were originally implemented as shell scripts and happened to invoke other commands like git checkout or git commit that would call the hooks.
Both backends should have the same behavior, though it is not entirely clear which, if any, is correct. We will likely make rebase stop calling either of these hooks in the future. The apply backend has safety problems with an ill-timed interrupt; if the user presses Ctrl-C at the wrong time to try to abort the rebase, the rebase can enter a state where it cannot be aborted with a subsequent git rebase --abort.
The merge backend does not appear to suffer from the same shortcoming. GC szeder. When a conflict occurs while rebasing, rebase stops and asks the user to resolve. Since the user may need to make notable changes while resolving conflicts, after conflicts are resolved and the user has run git rebase --continue , the rebase should open an editor and ask the user to update the commit message. The merge backend does this, while the apply backend blindly applies the original commit message.
There are a few more behavioral differences that most folks would probably consider inconsequential but which are mentioned for completeness:. Reflog: The two backends will use different wording when describing the changes made in the reflog, though both will make use of the word "rebase".
Progress, informational, and error messages: The two backends provide slightly different progress and informational messages. The merge mechanism git merge and git pull commands allows the backend merge strategies to be chosen with -s option.
This is the default merge strategy when pulling or merging one branch. This strategy can only resolve two heads using a 3-way merge algorithm.
When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge.
This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2. Additionally this strategy can detect and handle merges involving renames. It does not make use of detected copies. This option forces conflicting hunks to be auto-resolved cleanly by favoring our version.
Changes from the other tree that do not conflict with our side are reflected in the merge result. For a binary file, the entire contents are taken from our side. This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all.
It discards everything the other tree did, declaring our history contains all that happened in it. This is the opposite of ours ; note that, unlike ours , there is no theirs merge strategy to confuse this merge option with.
Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] -b , -w , --ignore-space-at-eol , and --ignore-cr-at-eol. If their version only introduces whitespace changes to a line, our version is used;. If our version introduces whitespace changes but their version includes a substantial change, their version is used;.
This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. Disables the renormalize option. This overrides the merge. Turn on rename detection, optionally setting the similarity threshold. This is the default. See also git-diff[1] --find-renames. This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging.
Instead, the specified path is prefixed or stripped from the beginning to make the shape of two trees to match. This can only resolve two heads using a 3-way merge algorithm. Additionally this can detect and handle merges involving renames. This was the default strategy for resolving two heads from Git v0. The recursive strategy takes the same options as ort. However, there are three additional options that ort ignores not documented above that are potentially useful with the recursive strategy:.
Use a different diff algorithm while merging, which can help avoid mismerges that occur due to unimportant matching lines such as braces from distinct functions.
See also git-diff[1] --diff-algorithm. Turn off rename detection. See also git-diff[1] --no-renames. This can only resolve two heads i. It tries to carefully detect criss-cross merge ambiguities. It does not handle renames. This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution.
It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch. This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches.
Note that this is different from the -Xours option to the recursive merge strategy. This is a modified ort strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level.
This adjustment is also done to the common ancestor tree. With the strategies that use 3-way merge including the default, ort , if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing.
It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits.
0コメント