From: Denton Liu Date: Fri, 29 Mar 2019 17:52:50 GMT Subject: Re: [PATCH v2] rebase: teach rebase --keep-base Message-ID: <20190329175250.GA18702@dev-l> In-Reply-To: Hi Johannes, On Fri, Mar 29, 2019 at 04:47:42PM +0100, Johannes Schindelin wrote: > Hi Denton, > > On Thu, 28 Mar 2019, Denton Liu wrote: > > > A common scenario is if a user is working on a topic branch and they > > wish to make some changes to intermediate commits or autosquash, they > > would run something such as > > > > git rebase -i --onto master... master > > > > in order to preserve the merge base. This prevents unnecessary commit > > churning. > > Maybe an example would clarify what you try to do here? Something like: > > Example: When contributing a patch series to the Git mailing list, > one often starts on top of the current `master`. However, while > developing the patch series, `master` is also developed further, > and it is sometimes not the best idea to keep rebasing on top > of `master`, but to keep the base commit as-is. In such a case, > the user can call > > git rebase -i --onto master... master > > as a shortcut to using the merge base between `master` and the > current branch as base commit. Will do, I'll include an example in the next reroll (probably in the docs too). > > I wonder, however, whether it makes sense to introduce a shorter, sweeter > way to do this: > > git rebase -i master... > > I.e. if we detect that the `` argument is not a valid ref, that > it ends with three dots, and that stripping those dots off makes it a > valid ref, then we internally convert that to the same as `--onto > master... master`. There's one use-case that this syntax wouldn't cover. Currently, if isn't specified, rebase automatically uses 'git merge-base --fork-point @{u} HEAD' as . This is even true for an invocation of 'git rebase --keep-base'. As a result, suppose we have the following graph o - f - o - U' origin/master \ U - A master where U used to be in origin/master (when we forked off) but upstream was rewound to drop it. If we run 'git rebase --keep-base', we'll get the following graph: o - f - o - U' origin/master \ A master i.e. we'll drop the commit dropped by upstream. I'm not entirely sure how useful this is, though, so if we decide to drop support for this use-case, then your proposed syntax will be fine. Thanks, Denton > > What do you think? > > Ciao, > Dscho > > > Alternatively, a user wishing to test individual commits in a topic > > branch without changing anything may run > > > > git rebase -x ./test.sh master... master > > > > Since rebasing onto the merge base of the branch and the upstream is > > such a common case, introduce the --keep-base option as a shortcut. > > > > This allows us to rewrite the above as > > > > git rebase -i --keep-base master > > > > and > > > > git rebase -x ./test.sh --keep-base master > > > > respectively. > > > > Add tests to ensure --keep-base works correctly in the normal case and > > fails when there are multiple merge bases, both in regular and > > interactive mode. Also, test to make sure conflicting options cause > > rebase to fail. While we're adding test cases, add a missing > > set_fake_editor call to 'rebase -i --onto master...side'. > > > > While we're documenting the --keep-base option, change an instance of > > "merge-base" to "merge base", which is the consistent spelling. > > > > Helped-by: Eric Sunshine > > Helped-by: Junio C Hamano > > Helped-by: Ævar Arnfjörð Bjarmason > > Signed-off-by: Denton Liu > > --- > > > > Ævar, I have a feeling that we're still miscommunicating and we don't > > fully understand each other. I'm putting up v2 to hopefully clear things > > up a little but I welcome more feedback. > > > > This patch now depends "[PATCH 1/8] tests (rebase): spell out the > > `--keep-empty` option" which is the first patch of Johannes's "Do not > > use abbreviated options in tests" patchset[1]. (Thanks for catching > > that, Johannes!) > > > > Changes since v1: > > > > * Squashed old set into one patch > > * Fixed indentation style and dangling else > > * Added more documentation after discussion with Ævar > > > > [1]: https://public-inbox.org/git/a1b4b74b9167e279dae4cd8c58fb28d8a714a66a.1553537656.git.gitgitgadget@gmail.com/ > > > > Documentation/git-rebase.txt | 25 ++++++++++++-- > > builtin/rebase.c | 32 ++++++++++++++---- > > t/t3416-rebase-onto-threedots.sh | 57 ++++++++++++++++++++++++++++++++ > > 3 files changed, 105 insertions(+), 9 deletions(-) > > > > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > > index 6363d674b7..27be1f48ff 100644 > > --- a/Documentation/git-rebase.txt > > +++ b/Documentation/git-rebase.txt > > @@ -8,8 +8,8 @@ git-rebase - Reapply commits on top of another base tip > > SYNOPSIS > > -------- > > [verse] > > -'git rebase' [-i | --interactive] [] [--exec ] [--onto ] > > - [ []] > > +'git rebase' [-i | --interactive] [] [--exec ] > > + [--onto | --keep-base] [ []] > > 'git rebase' [-i | --interactive] [] [--exec ] [--onto ] > > --root [] > > 'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch > > @@ -217,6 +217,19 @@ As a special case, you may use "A\...B" as a shortcut for the > > merge base of A and B if there is exactly one merge base. You can > > leave out at most one of A and B, in which case it defaults to HEAD. > > > > +--keep-base:: > > + Set the starting point at which to create the new commits to the > > + merge base of . Running > > + 'git rebase --keep-base ' is equivalent to > > + running 'git rebase --onto ... '. > > ++ > > +Although both this option and --fork-point find the merge base between > > + and , this option uses the merge base as the _starting > > +point_ on which new commits will be created, whereas --fork-point uses > > +the merge base to determine the _set of commits_ which will be rebased. > > ++ > > +See also INCOMPATIBLE OPTIONS below. > > + > > :: > > Upstream branch to compare against. May be any valid commit, > > not just an existing branch name. Defaults to the configured > > @@ -364,6 +377,10 @@ ends up being empty, the will be used as a fallback. > > + > > If either or --root is given on the command line, then the > > default is `--no-fork-point`, otherwise the default is `--fork-point`. > > ++ > > +If your branch was based on but was rewound and > > +your branch contains commits which were dropped, this option can be used > > +with `--keep-base` in order to drop those commits from your branch. > > > > --ignore-whitespace:: > > --whitespace=