On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter <ttmrich...@gmail.com> wrote: > On 30 December 2012 13:23, Nico Williams <n...@cryptonector.com> wrote: >> >> 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. > > > And why would I want to do this? Explain as you would to, say, a small > child.
Short version: because upstream tells you to. Longer version: first because upstream wants patches that apply cleanly, but if you don't have commit D in the new-feature branch and your commits a, b, and/or c require merging with D, then the upstream will tell you to update your patches (it's *your* job to do such merges), second because upstream may want you to re-organize your work (as I've explained before; no need to repeat). >> >> 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. > > > Why not, for example, just merge c into D or vice versa? I really don't see > what modifying history does here. Possibly because I lack the imagination > to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this > would be a desirable feature. Could you be more specific? Because D is already upstream, therefore to remove D from upstream would be a destructive operation. The goal is to produce new commits that apply cleanly to trunk upstream. Again, if I send a, b, and c upstream and D was missing in my branch then my commits may not apply cleanly. Even if they do the commit hashes will change as in the upstream the parent of a will be D, not C. >> A---B---C---D---a'---c'---b' (re-order commits, not merely change the >> base of commit a) > > > Why? Because upstream may ask for it. For example, if I wrote a test first, committed it, then a bug fix -- my mistake, but I should have done it the other way around (though I might not have known the upstream maintainer's order preferences upfront). >> >> A---B---C---D---a'---c' (drop a commit, not merely change the base of a) > > > Why? Because it turns out that commit b was lame. Or because upstream decided to reject commit b but commits a and c still stood on their own. >> >> A---B---C---D---abc' (merge all three of a, b, and c, into abc') > > > Why? Because upstream thought these three belong as one. (E.g., b might fix a bug introduced by a, and c might fix a typo in b.) >> >> A---B---C---D---ac'---b' (re-order and merge some) > > > Why? Commit c might fix a typo in commit a, while commit b might be unrelated. Squashing (git term) c into a then helps keep history clean upstream. Upstream likes clean history in official repos. >> >> A---B---C---D---a1'---a2'---b'---c' (split a and rebase) > > > Why? Because commit a did two separable things and upstream wants them separated so that, for example, a1' can be pulled into an older release's bugfix branch without pulling in a2'. >> >> A---B---C---abc' (no rebase, just merge the top three commits) > > > Why? Here I'm not contributing abc' just yet. I'm still working but I know upstream wants commits a, b, and c merged. Eventually I'll have to rebase onto D, but I want to do that later. >> These are things that upstream maintainers of large projects quite >> often insist upon. > > And why do they do this? I kinda/sorta get the mechanism. I just don't see > the motivation. (And "upstream maintainers insist upon this" is not > motivation, it's just moving the question of motivation around.) Because they want clean history. If commit b fixes a bug introduced by commit a then why should that bug -which had never been upstream to begin with- exist upstream in the middle of the history? Not only is there no reason to want that upstream, but having it upstream will only add to the burden of someone reviewing the history to understand it or specific changes in it. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
