Re: [OT?] git tools at SourceForge ?
On Sat, 13 Aug 2005, Martin Langhoff wrote:
Show 6 quoted lines
>
> > 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 ]
Show 6 quoted lines
> > 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
