Matthew D. Fuller wrote: > On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of > Jakub Narebski, and lo! it spake thus: >> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał: >> When two clones of the same repository (in git terminology), or two >> "branches" (in bzr terminology), used by different people, cannot be >> totally equivalent that is centralization bias. > > This is obviously some new meaning of "centralization" bearing no > resemblance whatsoever to how I understand the word. Perhaps I'd better use "star topology bias" instead of "centralization bias". > In git, apparently, you don't give a crap about a branch's identity > (alternately expressible as "it has none"), and so you throw it away > all the time. Given that, revnos even if git had them would never be > of ANY use to you, so it's no wonder you have no use for the notion. In git branches are lightweight. Branch names are local to repository. Repositories have identity. Bzr "branch" is strange mix of one-branch git repository and git branch. Git main workflow is fully decentralized workflow. All clones of the same repository are created equal. In bzr the suggested workflow (with revnos) forces one (or more) branches to be mainline (use "merge", get empty-merges, revnos don't change) and leaf (use "pull", revnos change). > I DO give a crap about my branchs' identities. I WANT them to retain > them. If I have 8 branches, they have 8 identities. When I merge one > into another, I don't WANT it to lose its identity. When I merge a > branch that's a strict superset of second into that second, I don't > WANT the second branch to turn into a copy of the first. If I wanted > that, I'd just use the second branch, or make another copy of it. I > don't WANT to copy it. I just want to merge the changes in, and keep > on with my branch's current identity. I don't understand. If I merge 'next' branch into 'master' in git, I still have two branches: 'master' and 'next'. And I don't understand why you are so hung on branch identities. Yes, if somebody clones your 'repo' repository, he can have your 'master' branch (refs/heads/master) named 'repo' (refs/heads/repo) or 'repo/master' (refs/remotes/repo/master), but why that matters to you. It is _his_ (or her ;-) clone. > Now, we can discuss THAT distinction. I'm not _opposed_ to git's > model per se, and I can think of a lot of cases where it's be really > handy. But those aren't most of my cases. And as long as we don't > agree on branch identity, it's completely pointless to keep yakking > about revnos, because they're a direct CONSEQUENCE of that difference > in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't > have revnos, I'd STILL want my branch to keep its identity. You could > name the mainline revisions after COLORS if you wanted, and I'd still > want my branch to keep its identity. Aren't we through rehashing the > same discussion about the EFFECTS? For revnos to work you MUST have one "branch" to be considered special, the hub in star topology. This very much precludes fully distributed development. BTW. I get that you can use revids in revnos in bzr for fully distributed and not star-topology geared development. But Bazaar-NG revids are uglier that Git commit-ids. [...] >> And you say that bzr is not biased towards centralization? In git >> you can just pull (fetch) to check if there were any changes, and if >> there were not you don't get useless marker-merges. > > If I don't tell you my branch has something in it ready to grab, you > shouldn't merge it. It probably won't work, and is quite likely to > set your computer on fire, slaughter and fillet your pet goldfish, and > make demons fly out of your nose. If you wanna get stuck with all my > incomplete WIP, let's just use a CVS module and be done with it. In git I can fetch your changes but I don't need to merge them. Take for example Junio 'pu' (proposed updates) branch: this is the branch you shouldn't merge as it's history is constantly being rewritten. If you don't want for your WIP to be publicly available, you don't publish it. For example as far as I understand Junio works on Git in his private repository, with many, many feature branches, but he does push to public [bare] repository only some subset of branches, and we can fetch/pull only those. But still, if I am impatient I can pull from Junio every hour, and I don't get 24 totally useless empty merge messages if he took day off and didn't publish any changes till day later. >> 2. But the preferred git workflow is to have two branches in each of >> two clones. The 'origin' branch where you fetch changes from other >> repository (so called "tracking branch") and you don't commit your >> changes to [...] > > Funny, since this reads to me EXACTLY like the bzr flow of "upstream > branch I pull" and "my branch I merge from upstream" that's getting > kvetched around... But please, have you realized that in this workflow the two clones of the same repository are totally symmetrical? One's 'master' is another 'origin' and vice versa. After pull on one side, and pull on the other side (without any changes in between) we have the same contents, and the same revision names (commit-ids in git), even if the changes (revisions) got to those clones in different order. In bzr those two "branches" would get different revnos. No symmetry. Full distributed vs star topology (one branch "central", hence "centralized" - I don't mean need to access to one central repository, although...) -- Jakub Narebski ShadeHawk on #git 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