Re: rebase -p confusion in 1.6.1

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 15, 2009, 13:58 UTC
Message-ID: <alpine.DEB.1.00.0901151448120.3586@pacific.mpi-cbg.de>
In-Reply-To: <20090115133808.GA10045@leksak.fem-net>

Hi,

On Thu, 15 Jan 2009, Stephan Beyer wrote:

Show 15 quoted lines

> Hmm, you are rebasing onto master which is merged into the branch you 
> want to rebase. So, I think the correct output should be the same like 
> git rebase without -p, ie
> 
> * 1337bee... (refs/heads/work) b4
> * deadbee... b3
> * badbeef... b2
> * fa1afe1... b1
> * 0153c27... (refs/heads/master) a4
> * 74f4387... a3
> * b37ae36... a2
> * ed1e1bc... a1
> 
> This is because master is already merged into work and a preserved
> merge will see that everything is already merged in.

I guess the problem is that the list shown in the editor says 'noop'. This does not happen without -p, so something is borked in the commit listing with -p.

Which is no wonder: the code after line 652 in git-rebase--interactive.sh that handles -p is utterly incomprehensible.

Remember: there is code that is so simple that it has no obvious flaws, 
and there is code that is so complicated that it has no obvious flaws.

IMO (and I said so much back then), it was the biggest mistake of the whole patch series that it was so intrusive and changed everything. It's not like I did not warn anybody.

The point is: you could _easily_ handle -p with _almost the same_ rev-list command; you'd just have to make sure that --no-merges is skipped.

And then you only have to make sure that the current commit is the (possibly rewritten version of the) first parent of the next commit to pick.

Ciao, Dscho