Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
