A minimal builtin rebase#32
Closed
dscho wants to merge 11 commits intogitgitgadget:pk/rebase-in-cgitgitgadget/git:pk/rebase-in-cfrom
Closed
A minimal builtin rebase#32dscho wants to merge 11 commits intogitgitgadget:pk/rebase-in-cgitgitgadget/git:pk/rebase-in-cfrom
dscho wants to merge 11 commits intogitgitgadget:pk/rebase-in-cgitgitgadget/git:pk/rebase-in-cfrom
Conversation
The `--onto` option is important, as it allows to rebase a range of commits onto a different base commit (which gave the command its odd name: "rebase"). This commit introduces options parsing so that different options can be added in future commits. Note: As this commit introduces to the parse_options() call (which "eats" argv[0]), the argc is now expected to be lower by one after this patch, compared to before this patch: argv[0] no longer refers to the command name, but to the first (non-option) command-line parameter. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit implements support for an --onto argument that is actually a "symmetric range" i.e. `<rev1>...<rev2>`. The equivalent shell script version of the code offers two different error messages for the cases where there is no merge base vs more than one merge base. Though it would be nice to retain this distinction, dropping it makes it possible to simply use the `get_oid_mb()` function. Besides, it happens rarely in real-world scenarios. Therefore, in the interest of keeping the code less complex, let's just use that function, and live with an error message that does not distinguish between those two error conditions. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit converts the equivalent part of the shell script `git-legacy-rebase.sh` to run the pre-rebase hook (unless disabled), and to interrupt the rebase with error if the hook fails. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit introduces a rebase option `--quiet`. While `--quiet` is commonly perceived as opposite to `--verbose`, this is not the case for the rebase command: both `--quiet` and `--verbose` default to `false` if neither `--quiet` nor `--verbose` is present. Despite the default being `false` for both verbose and quiet mode, passing the `--quiet` option will turn off verbose mode, and `--verbose` will turn off quiet mode. This patch introduces the `flags` bit field, with `REBASE_NO_QUIET` as first user (with many more to come). We do *not* use `REBASE_QUIET` here for an important reason: To keep the implementation simple, this commit introduces `--no-quiet` instead of `--quiet`, so that a single `OPT_NEGBIT()` can turn on quiet mode and turn off verbose and diffstat mode at the same time. Likewise, the companion commit which will introduce support for `--verbose` will have a single `OPT_BIT()` that turns off quiet mode and turns on verbose and diffstat mode at the same time. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit introduces support for the `-v` and `--stat` options of rebase. The --stat option can also be configured via the Git config setting rebase.stat. To support this, we also add a custom rebase_config() function in this commit that will be used instead of (and falls back to calling) git_default_config(). Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit reads the index of the repository for rebase and checks whether the repository is ready for rebase. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In this commit, we add support to fast forward. Note: we will need the merge base later, therefore the call to can_fast_forward() really needs to be the first one when testing whether we can skip the rebase entirely (otherwise, it would make more sense to skip the possibly expensive operation if, say, running an interactive rebase). Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In this commit, we add support to `--force-rebase` option. The equivalent part of the shell script found in `git-legacy-rebase.sh` is converted as faithfully as possible to C. The --force-rebase option ensures that the rebase does not simply fast-forward even if it could. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To run a new rebase, there needs to be a check to assure that no other rebase is in progress. New rebase operation cannot start until an ongoing rebase operation completes or is terminated. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When running a rebase on a detached HEAD, we currently store the string "detached HEAD" in options.head_name. That is a faithful translation of the shell script version, and we still kind of need it for the purposes of the scripted backends. It is poor style for C, though, where we would really only want a valid, fully-qualified ref name as value, and NULL for detached HEADs, using "detached HEAD" for display only. Make it so. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit adds support for `switch-to` which is used to switch to the target branch if needed. The equivalent codes found in shell script `git-legacy-rebase.sh` is converted to builtin `rebase.c`. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
|
/submit |
|
Submitted as pull.32.v2.git.gitgitgadget@gmail.com |
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Sep 4, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Nov 1, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
|
This branch is now known as |
Member
Author
|
This patch series was integrated into pu via git@eeb9e5b. |
Member
Author
|
This patch series was integrated into next via git@c2a0046. |
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Nov 5, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Nov 5, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Nov 5, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This comment has been minimized.
This comment has been minimized.
Member
Author
|
This patch series was integrated into pu via git@e0720a3. |
Member
Author
|
This patch series was integrated into next via git@e0720a3. |
Member
Author
|
This patch series was integrated into master via git@e0720a3. |
Member
Author
|
Closed via e0720a3. |
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Nov 5, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Dec 15, 2018
It is pretty nice to use GitGitGadget. But what if a patch series had already been started without GitGitGadget? Fear not. This script can be used to initialize the PR metadata accordingly. It is still a very manual, error-prone process (the information about the number of patches should be taken from the cover letter, the tip commit should be verified against the latest diff, and the base commit should be determined automatically, just like the iteration). If need be, we can start from here, automating one little piece by one little piece. The primary reason for this was to allow submitting v2 iterations for rebase-in-c-2-basic and rebase-in-c-4-opts: gitgitgadget/git#32 and gitgitgadget/git#33 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch series provides the bare minimum to run more than just the trivial rebase (i.e.
git rebase <upstream>): it implements the most common options such as--onto.It is based the latest iteration of pk/rebase-in-c.
This is the second patch series that brings us more closer to a builtin "git rebase".
Changes since v1: