2006/10/18, Andreas Ericsson <ae@xxxxxx>:
Aaron Bentley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Carl Worth wrote: >> Aaron, thanks for carrying this thread along and helping to bridge >> some communication gaps. For example, when I saw your original two two >> diagrams I was totally mystified how you were claiming that appending >> a couple of nodes and edges to a DAG could change the "order" of the >> DAG. >> >> I think I understand what you're describing with the leftmost-parent >> ordering now. But it's definitely an ordering that I would describe as >> local-only. That is, the ordering has meaning only with respect to a >> particular linearization of the DAG and that linearization is >> different from one repository to the next. > > Well, the linarization for any particular head is well-defined, but > since different branches have different heads... > >> If in practice, nobody does the mirroring "pull" operation then how >> are the numbers useful? For example, given your examples above, if >> I'm understanding the concepts and terminology correctly, then if A >> and B both "merge" from each other (and don't "pull") then they will >> each end up with identical DAGs for the revision history but totally >> distinct numbers. Correct? > > The DAGs will be different. If A merges B, we get: > > a > | > b > |\ > c d > |\| > | e > |/ > f > > If B merges A before this, nothing happens, because B is already a > superset of A. > > If B merges afterward, we get this: > a > | > b > |\ > d c > |/| > e | > |\| > | f > |/ > g > Seems like an awful lot of merge commits. In git, I think these trees would be identical (actually both to bazaar and to each other), with the exception that the 'g' commit wouldn't exist, since git does fast-forward and relies on dependency-chain only to present the graph instead of mucking around with info in external files (recording of fetches).
Ok. This I don't get. Let me recaptulize: Branch A a | b | c Branch B a | b | \ d c | / e In branch A, do merge branch B (git pull B) you get as result branch B, because A fastforwards to B and you don't get a merge commit f In branch B, do merge branch A (git pull A), the result would be branch B, because we are already uptodate. You _never_ have a commit f or g. -Peter - 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