Daniel Barkalow [off-list ref] writes:
On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
quoted
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.
On 2007.12.28 12:33:41 -0600, adr3nald0s@gmail.com wrote:
Daniel Barkalow [off-list ref] writes:
quoted
On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
quoted
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.
quoted
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.
I wouldn't make sense either. The conflict resolution that was done in
the merge commit might need stuff from commits that haven't been rebased
yet. For example a new function that was introduced later, it was
available for the merge, but is still missing from the rebased linear
history.
That said, what _might_ make sense is to teach interactive rebase with
-p to use "cherry-pick -m1" or whatever instead of "merge" to recreate
the merge commits (or maybe it does that already now? didn't check...).
That way, it wouldn't have to rely on rerere being enabled to avoid the
repeated resolving of the merge conflicts. I'm not sure how that would
need to interact with new changes introduces into one of the rewritten
branches.
Björn