Re: Anomalous conflicts during git rebase

From: adr3nald0s@gmail.com <adr3nald0s@gmail.com>
Date: Dec 28, 2007, 18:33 UTC
Message-ID: <m3fxxm7jp6.fsf@euroclydon.lan>
In-Reply-To: <alpine.LNX.1.00.0712281246330.13593@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 9 quoted lines

> On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
>
>> When you say it linearizes history how is this done.
>
> Rebase takes a list of commits that are in the current branch and 
> aren't in the origin branch as what it's going to work on; these are 
> ordered in some arbitrary way such that children always follow parents. It 
> then resets to the origin branch's commit, and, in sequence, cherry-picks 
> each of the commits in the working list.

Thanks again for the clear explanation.

> In theory, of course, it could try to resolve conflicts by looking through 
> the rest of the list for merges which would have those conflicts and using 
> what that merge did.

Given the implementation, this would be just plain ugly. I would not want to attempt to implement something like this, nor would I expect anyone else to do so.