Hi Junio,
On Sun, Mar 24, 2019 at 10:20:28PM +0900, Junio C Hamano wrote:
> Denton Liu <liu.den...@gmail.com> writes:
>
> > A common scenario is if a user is working on a topic branch and they
> > wish to make some changes to intermediate commits or autosquashing, they
> > would run something such as
> >
> > git rebase -i --onto master... master
> >
> > in order to preserve the merge base. This prevents unnecessary commit
> > churning.
> >
> > 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.
>
> I never use the "feature" myself, but I recall that when "git
> rebase" is run on a branch appropriately prepared, you do not even
> have to say <upstream> (iow, you type "git rebase<RET>" and rebase
> on top of @{upstream}).
>
> Can this new "--keep-base" feature mesh well with it? When the
> current branch has forked from origin/master, for example, it would
> be good if
>
> $ git rebase -i --same-base
>
> becomes a usable short-hand for
>
> $ git rebase -i --same-base origin/master
By "--same-base", I am assuming you mistyped and meant to write
"--keep-base"? If that's the case, I can make it a shorthand.
Thanks,
Denton
>
> aka
>
> $ git rebase -i --onto $(git merge-base HEAD origin/master)
> origin/master
>
