Re: [PATCH v9 9/9] rebase: teach rebase --keep-base
- From
Philip Oakley <philipoakley@iee.email>
- Date
- Aug 25, 2019, 22:59 UTC
- Message-ID
- <3ffbaead-27e5-1b1a-5ad1-1136697cea1d@iee.email>
- In-Reply-To
- <6927aba6176fb1b6f30c63e7d8c096861b2f0141.1566724236.git.liu.denton@gmail.com>
On 25/08/2019 10:12, Denton Liu wrote:
Show 9 quoted lines
> 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 is useful when contributing a > patch series to the Git mailing list, one often starts on top of the > current 'master'.
This 'However' part doesn't fit the flow. Do you mean 'while initially developing...', or is the choice of 'However' wrong?
> However, while developing the patches, '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. >
This 'Alternatively' appears to be part of the first set of common scenarios. Maybe it's just 3 common scenarios, all justifying the same improvement.
Show 17 quoted lines
> 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.
[remainder snipped] [also Eric Sunshine dropped due to temporary sending difficulties]
Philip