Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase
- From
Andreas Ericsson <ae@op5.se>
- Date
- Sep 24, 2008, 07:13 UTC
- Message-ID
- <48D9E898.1020305@op5.se>
- In-Reply-To
- <20080924001027.GA19264@neumann>
SZEDER Gábor wrote:
Show 54 quoted lines
> Hi Andreas, > > First of all, thanks for the work! > > On Tue, Sep 23, 2008 at 11:30:09PM +0200, Andreas Ericsson wrote: >> It requires a bit of testing though. All the t/t34* tests pass with >> all the patches applied, and some manual tries worked just fine too, >> but if you wanna give it a twirl where you work, that'd be great. > Unfortunately in my example workflow[1] posted earlier today your > patch series does not work in the way I would like it to behave. > > The following DAG is created by the commands below: > > -A---B master > \ > C---M topic > \ / > D > > git init > echo 1 >foo > git add foo > git commit -m 'first on master' # A > echo 2 >>foo > git commit -m 'second on master' foo # B > git checkout -b topic HEAD^ > echo 1 >bar > git add bar > git commit -m 'first on topic' # C > git checkout -b subtopic > echo 1 >baz > git add baz > git commit -m 'first on subtopic' # D > git checkout topic > git merge --no-ff subtopic # M > > If I now execute 'git rebase -p master topic', I get the following: > > -A---B master > \ \ > \ C'---M' topic > \ / > C----D > > But I would rather like to have the following: > > -A---B master > \ > C'---M' topic > \ / > D' > > Would such a behaviour possible at all? >
See Johannes Sixt's reply (git sequencer). What I provided was a hack to access existing functionality in a way that was previously not possible. While that can be neat in itself, the patch series doesn't alter how the merge-preserving rebase works in the slightest.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231