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
On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
Daniel Barkalow [off-list ref] writes:
quoted
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*