Hi
On 09/09/2019 15:13, Johannes Schindelin wrote:
Hi,
On Mon, 9 Sep 2019, Phillip Wood wrote:
On 08/09/2019 00:44, Warren He wrote:
Everyone in this thread, thanks for your support and encouragement.
[...]
It should not really imply `--interactive`, but `--rebase-merges`.
`imply_interact
Johannes Schindelin writes:
> In contrast, I would think that
>
> label --update-branch my-side-track
>
> would make for a nicer read than
>
> label my-side-track
> branch my-side-track
Because labelling while recreating a mergey history is conceptually
the same as temporarily
Hi,
On Mon, 9 Sep 2019, Phillip Wood wrote:
> On 08/09/2019 00:44, Warren He wrote:
> > Everyone in this thread, thanks for your support and encouragement.
> > [...]
> > > It should not really imply `--interactive`, but `--rebase-merges`.
> >
> > `imply_interactive` doesn't fully switch on `--int
Hi Warren
On 08/09/2019 00:44, Warren He wrote:
Everyone in this thread, thanks for your support and encouragement.
[...]
It should not really imply `--interactive`, but `--rebase-merges`.
`imply_interactive` doesn't fully switch on `--interactive`, i.e., causing the
editor to open. It only s
Rebasing normally updates the current branch to the rewritten version.
If any other branches point to commits rewritten along the way, those
remain untouched. This commit adds an `--update-branches` option, which
instructs the command to update any such branches that it encounters to
point to the r
Everyone in this thread, thanks for your support and encouragement.
Johannes, thanks for reviewing.
> Maybe `s/reapplied/rebased/`?
Ok. I've changed most occurrences, except in Documentation/git-rebase.txt, where
the term 'reapplied' is already in use.
> drop this hunk and only keep the next on
6 matches
Mail list logo
