On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter <ttmrich...@gmail.com> wrote: > On 30 December 2012 12:56, Nico Williams <n...@cryptonector.com> wrote: >> >> What is it about rebase that causes so many to miss the idea of a >> rebase that is NOT destructive because it creates a new branch instead >> of doing a destructive change to an existing branch? > > I don't know. You won't explain it. "It's too much work," remember?
You had left me under the impression that you knew what git rebase is. Fair enough, here we go: A "rebase" operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since <oldbase> then b) creates a new line of commits that consists of <newbase> plus the commit set computed in (a), each commit in that set applied as a delta onto <newbase>, merging as needed. So, if we have a branch called "trunk" with this history: A---B---C---D and a branch called "new-feature" with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. In *git* this is a destructive operation because the new-feature branch's HEAD is made to be c', which is not a linear history from c. But if the rebase operation creates a new branch whose HEAD points to c' then there's nothing destructive. Other things that can be redone in a rebase would include: A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) A---B---C---D---a'---c' (drop a commit, not merely change the base of a) A---B---C---D---abc' (merge all three of a, b, and c, into abc') A---B---C---D---ac'---b' (re-order and merge some) A---B---C---D---a1'---a2'---b'---c' (split a and rebase) A---B---C---abc' (no rebase, just merge the top three commits) These are things that upstream maintainers of large projects quite often insist upon. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
