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
aka
$ git rebase -i --onto $(git merge-base HEAD origin/master)
origin/master
