On Sat, 21 Oct 2006, Jakub Narebski wrote:
quoted text
> 
> That's good example of fully distributed approach. I can fetch directly
> (actually, I cannot) from Junio private repository, I can fetch from
> public git.git repository, either using git:// or http:// protocol,
> I can fetch from somebody else clone of git repository: intermixing
> those fetches, and revids (commit-ids) remain constant and unchanged.

This is nice for a couple of situations:

 - if some particular machine is down, nobody really cares. It doesn't 
   really change the workflow at all if "master.kernel.org" were to be 
   off-line due to some trouble - it just happens to be a machine with 
   good bandwidth that a number of kernel (and git) developers have access 
   to, but if you want to sync with something else, go wild. We could just 
   sync directly between developers, although most people tend to have 
   firewalls (I certainly have a very anal one - not even ssh gets in) 
   making it usually easier to go through some - any - public place.

   But in git, the "public place" really is just an intermediary. It has 
   nothing to do with anything history-wise, and it's revision ID's are a 
   non-issue. It's just a temporary staging area (although re-using the 
   same repo over and over for pushing things out obviously means you can 
   do just incremental updates, so most everybody does that)

 - sometimes you have multiple branches in the same tree that have very 
   _different_ sources. For example, you might start out cloning my tree, 
   but if you _also_ want to track the stable tree, you just do so: you 
   can just do

	git fetch <repo> <remote-branch-name>:<local-branch-name>

   at any time, and you now have a new branch that tracks a different 
   repository entirely (to make it easier to keep track of them, you'd 
   probably want to make note of this in your .config file or your remote 
   tracking data, but that's a small "usability detail", not a real 
   conceptual issue).

 - the same "multi-source" thing is true for pushing things out too, not 
   just fetching: I still have my personal git.git repository on 
   kernel.org for historical reasons, even though Junio maintains the 
   normal one. So when I did some experimental (and broken) stuff for "git 
   unpack-objects" in a local branch, and others were interested in fixing 
   it, I just pushed it out to my git repo as a new branch - one that 
   Junio doesn't have.

   So now my kernel.org git repo not only tracks all of Junio's branches 
   (basically just a mirror of his tree), I also have a few stale branches 
   of my own that I did some work on separately. So it's kind of a 
   "frankensteins monster" of different branches from different sources. 

   And I think that's fairly common, actually (ie many kernel developers 
   that publicise their own git trees often have a "linus" branch that 
   tracks mine, along with their own "real" branches)

And note how in none of these situtations does it matter what the 
"original" branch was. It might even be a way to just pre-populate the 
tree. For a real-life example, a week or two ago, Jesper Juhl wanted to 
download my kernel tree (which is about 140MB in size), but he's somewhere 
in Europe, and apparently the connection to kernel.org was just _really_ 
slow. 

So what I told him to do was:

   Hmm. I suspect most mirrors avoid the /pub/scm directory, but there are a 
   few places that mirror git trees in general, eg

        http://www.jur-linux.org/git/

   might be closer to you.

   Once you have _one_ kernel repo, you can clone another easily using

        git clone --reference <mylocalrepo> <remotereponame> [localdir]

   but you do need to have the thing in git format, not just a snapshot, to 
   do that.

and that's exactly what he did (and he could have just fetched into the 
original archive entirely):

   I could only get 2-3kb/sec from kernel.org and at that speed 140MB is 
   *HUGE*.

   That was a lot better. got more than 200kb/sec from there.

so the point here is, "distributed" really is more than star-topology. If 
you think outside the star, you can take useful shortcuts.

Now, I'm sure that bzr can probably do all the same things. This is likely 
less an issue of "technology" than of "mindset". The "git way" tends to 
make all of these things very trivial - the notion of tracking multiple 
branches from multiple _different_ repositories in one local repo just 
fits very naturally in the whole git mentality.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html