Andreas Ericsson wrote: > Matthew D. Fuller wrote: >> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of >> Carl Worth, and lo! it spake thus: >> >>> (since pull seems the only way to synch up without infinite new >>> merge commits being added back and forth). >> >> The infinite-merge-commits case doesn't happen in bzr-land because we >> generally don't merge other branches except when the branch owner says >> "Hey, I've got something for you to merge". If you were to setup a >> script to merge two branches back and forth until they were 'equal', >> yes, it'd churn away until you filled up your disk with the N bytes of >> metadata every new revision uses up. > > This is new to me. At work, we merge our toy repositories back and forth > between devs only. There is no central repo at all. Does this mean that > each merge would add one extra commit per time the one I'm merging with > has merged with me? >From what I understand, "bzr merge" will create one extra commit to preserve the "first parent is my branch" feature. "bzr pull" will do fast-forward if your DAG is proper subset of pulled branch/repository DAG, but at the cost that it would change your revno to revision mapping to those of the pulled repository. That's a consequence of preserving branch as "my work" i.e. as path through "branch DAG" in the DAG using first parent as special, instead of saving it outside DAG. -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html