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. That's just the SVN way of doing things, which is
just silly.
Folding commits together makes sense if you have, say, one commit
implementing some feature and two subsequent commits adding minor fixes
to it.
- Alex
