The 'original' history is useful in cases where you're sure it worked earlier. After a rebase you don't have the commits from earlier anymore.
On Sun, Feb 13, 2011 at 4:01 AM, Reinier Zwitserloot <reini...@gmail.com> wrote: > That's one part of the rebase story - 'public' vs 'private' commits. hg > squash commit does mostly the same thing. > The other part of rebase is to make the repository look as linear as > development could have been. > > Common scenario: > Joe wakes up, updates master branch, and starts work on a bunch of features. > Joe finishes near the end of the day, clean up commits (the 'first' meaning > of rebase), and pushes this to the repo. > Jack does the exact same thing. > > One of the two can push, no problem. The other gets an out of sync error and > needs to pull (fetch) first. This fetch/pull will result in an automatic > merge (no need for manual conflict resolution, fortunately, unless both Jack > and Joe made changes to the same stuff or very close to each other in the > same file). > > The end result is a merge in the tree view. > > But.... Joe was working on feature X and Jack on completely unrelated > feature Y. On svn / cvs there'd never have been any branch anywhere, as > those are file-level instead of repo-level. The merge is a completely > irrelevant artefact is only going to cause pointless confusion and annoyance > if anyone else attempts to review the day's work. If Jack had waited for Joe > to finish work and push changes, there'd be no merge. > > The second take on rebase fixes this problem; Joe would notice the out of > sync error, rebase the *BRANCH* where he did his day's work on (because in > git, you should always be working on a branch, for everything, which also > explains why you don't want branch names to stick around. If everyone on the > project came up with 3 branch names every day, you'd run out of names in a > heartbeat), and then commit this. The repo tree view would be one straight > line. > Of course if actual merging took place this won't work, and you'll just > commit the merge, nicely storing into the annals of history that some quit > relevant merging took place. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
