Re: Anomalous conflicts during git rebase

Daniel Barkalow [off-list ref] 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?

Thanks again.

-- 
Adr3nalD0S