Alex R�nne Petersen Wrote: > On 02-11-2011 16:33, Kagamin wrote: > > Alex Rønne Petersen Wrote: > > > >> 3) This is absolutely essential in distributed development. When you > >> work on a large feature in a fork, you typically end up with lots of > >> commits. When you send this work upstream, you don't want to cause noise > >> in the history. Rebasing helps in avoiding this by squashing commits > >> together to get a nice, clean history. > > > > I thought, a developer pushes his changes as a branch, which is later > > merged to main. Merge is done as one big commit, so the main branch looks > > like 1. merge database, 2. merge collections, 3. merge gui - isn't this > > your clean history? > > The merge itself can be a commit (if you use git merge instead of git > pull), but there is no reason to eliminate the *entire* history when > pulling in a branch.
Isn't the merge commit connected with the branch it was merged from? So if you want history of the branch, it's still there, it's just not main's history.
