On Sat, 13 Aug 2005, Martin Langhoff wrote:
>
> > Yes, developers can just merge with each other directly
>
> I take it that you mean an exchange of patches that does not depend on
> having public repos. What are the mechanisms available on that front,
> other than patchbombs?
Just have a shared trusted machine.
A lot of "core" developers end up having machines that they may not
control, and that they may not be able to use as major distribution
points, but that they _can_ share with others.
For example, "master.kernel.org" ends up being that for the kernel: you
don't have to have an account on master, but most of the core developers
do, so they can use it as a short-cut that is independent of the actual
"public" site.
Similarly, some people are perfectly willing to give other trusted
developers a ssh login on their machine - and that's a perfectly fine way
to sync repositories directly if you have even a slow DSL link. You'd
never want to _distribute_ the result over DSL, though.
The point being that you can certainly sync up to others without going
through a public site.
[ We _could_ also just send pack-files as email attachments. There's
nothing fundamentally wrong with doing the object discovery that
"git-send-pack" does on its own manually over email.
In other words: you could easily do something like "Hey, I've got your
commit as of yesterday, ID <sha1>, can you send me your current
top-of-tree SHA1 name and the pack-file between the two?" and have
direct git-to-git synchronization even over email.
NOTE NOTE NOTE! BK did this, with a "bk send" and "bk receive". I hated
it, which is why I'd never do scripts like that. But I think it's a
valid thing to do when you're cursing the fact that the central
repository is down, and has been down for five hours, and you don't know
how long it will take to get back up, and you don't have _any_ other
choices ]
> > This is _exactly_ where something like SF really ends up being helpful.
> > It's a _hosting_ service, and git is eminently suitable to being
>
> Not sure whether SF is offering rsync, but they do support hosting of
> arbitrarty data -- and a project using GIT can use that to host
> several developer trees.
The problem with the arbitrary data approach (and rsync) is that the git
repositories can get out of sync.
We haven't seen it very often on kernel.org, but we _do_ see it. I think
I've got something like three bug reports from people saying "your tree is
corrupted" because it so happened that the mirroring was on-going at the
same time I did a push, and the mirroring caught an updated HEAD without
actually having caught all of the objects that HEAD referenced.
Now, all the git tools do write things in the right order, and mirror
scripts etc _tend_ to mirror in alphabetical order (and "objects" come
before "refs" ;), so you really have to hit the right window where a git
tool updates the git repository at the same time as a mirroring sweep is
going on, but it definitely _does_ happen.
It just happens seldom enough that most people haven't noticed. But if
you've seen the gitweb page go blank for one of the projects, you now know
why it can happen..
And this is inevitable when you have a non-git-aware server. You really
need to update the objects in the right order, and to get the right order
you do have to be git-aware.
> It'd be nice if SF offered gitweb and
> similar niceties. As my usage of GIT increases, I may add support for
> it on Eduforge.org
I think we'll find that it's a learning process, to just find out what
drives site managers mad (we certainly found the problem with lots of
small files on kernel.org out ;). Having a few sites that do it and tell
the others what gotchas there are involved with it (and what scripts they
use for maintaining stuff like auto-packing etc) is all a learning
experience.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
