Show HN: git clone, git pull with no central repository | Hacker News Reader

Show HN: git clone, git pull with no central repository

pagekite.net

46 pointsHerraBRE18 comments

There's also Bananajour if you want to share on the local network: https://github.com/toolmantim/bananajour

That looks pretty neat. Is it just a bonjour enabled web interface, or does it do other stuff? If it's mostly a web UI, you may be able to expose that using PageKite too, for sharing over the Internets:

pagekite.py localhost:9331 bananajour-youraccount.pagekite.me

isn't it the very nature of a distributed vcs to be able to work without a central repository? I like the post, but I think the title is misleading ( sorry to be that guy ).

That is exactly the point! :-)

Dvcs systems have that potential, but people still generally fall back to using a central repo for sharing, because the network gets in the way of direct push/pull. The point of the article is to show one way of working around that.

If you follow it to its logical conclusion, then every member of a team can expose their working repo and any member can pull from any other member at any time.

But once you go that path... good luck figuring out what feature got merged when, what are the dependencies, what's the correct versioning, etc.

Why would you keep it that way instead of defining some central repository which contains the current dev branch?

It depends on the project really, centralization has many advantages. I just thought being able to go fully distributed was a neat hack.

This may be obvious but you can pull with ssh directly from workstation to another.

Only if you create accounts and your workstations can reach each-other somehow. That is more effort and won't work at all if the workstation is behind a firewall on some remote network.

LDAP/kerberos (or similar centralized account system) or "anonymous" account (no password) alleviates auth problems. Routing traffic to the machines is as problematic with HTTPS as it is with SSH. SSH tunnels can be used instead of pagekite.

True enough, but for work within your company these conditions are likely already met. And while your company could easily have an internal central repository server (we use RhodeCode in our lab), not everyone might want to (or have permission to) push into the central repo.

I know a company that essentially only commits changes to their subversion server once they're ready to be shipped to the client. Their developers just work on (unrevisioned) private copies and distribute changes to one another manually. Makes me cringe. I've been introducing some of them to DVCS as I interact with them (they send me a zip file full of code to look at, I send them back a link to a repo containing their zip file contents and my patches), but I don't think they're quite getting it yet.

Exactly! One of my favorite tricks. Any decent shared host can serve as a makeshift git repository.

This is very cool. But the problem is many of us are behind restrictive firewalls, nats, and proxy. If you could find a fix for that I personally would be really cheering for you.

That is exactly what PageKite does, you should try it. :-)

I am hooked :)

Essentially, one could simply copy the .git folder to a web visible place:

  cp -r .git ~/public_html/foo.git

I'd rather symlink it. :-)

Of course, I'd wager not very many of us work all the time on web-visible machines, which is why adding PageKite changes things - I'm sharing repos off my laptop now.

Apart from a couple of short consulting jobs, it's been 17 years since I last worked on a machine that wasn't web visible...

I couldn't imagine not being able to ssh in to screen session with my exact current state of work and/or access work in progress websites directly...

I just discovered this trick yesterday, and thought it was so awesome I had to write about it. Truly decentralized code sharing! :-)

Reply on news.ycombinator.com