Re: Anomalous conflicts during git rebase

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Dec 28, 2007, 17:58 UTC
Message-ID: <alpine.LNX.1.00.0712281246330.13593@iabervon.org>
In-Reply-To: <m3k5my7r1u.fsf@euroclydon.lan>

On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:

Show 20 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > This will rebase temp0 (= v2.6.16) onto topic/test. This process 
> > linearizes the history being rebased, and conflicts in that history (that 
> > were resolved in the merges) show up when the second change to those lines 
> > gets introduced.
> 
> Thank you for the explaination of why this is happening.  This is
> something I had not considered WRT git-rebase.
> 
> When you say it linearizes history how is this done.  Mentally I still
> have a model of where the "mainline" is at all times and I assumed
> that git-rebase was following this mainline.  However, upon
> reflection, I realize this is naïve.
> 
> When there is a branch and a subsequent merge, does rebase follow both
> branches?  If so, why does it not use the original merged result for
> the newly rebased file if there are no conflicts between the original
> merge result and the file that is being rebased onto as compared to
> their mutual ancestor?

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. This has two implications:

 - the result is always linear, even if there are forks and merges in the 
   old history, because the new history is formed out of a single sequence 
   of cherry-picks, ignoring the shape of the original.

 - merge results from the old history aren't available, because they're in 
   a commit later in the list than the commit where the cherry-picking 
   finds a conflict.

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. But that's not at all easy, due to the structure of the process, and it's rare that people actually want to rebase history with forks in it, anyway, so it hasn't been done.

	-Daniel
*This .sig left intentionally blank*