5 ms·

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

46 points by HerraBRE 15y ago

HerraBRE 15y ago
I just discovered this trick yesterday, and thought it was so awesome I had to write about it. Truly decentralized code sharing! :-)
SaltwaterC 15y ago
Does it use Smart HTTP Transport? http://progit.org/2010/03/04/smart-http.html http://progit.org/2010/03/04/smart-http.html
judofyr 15y ago
There's also Bananajour if you want to share on the local network: https://github.com/toolmantim/bananajour https://github.com/toolmantim/bananajour
- HerraBRE 15y ago
  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
beza1e1 15y ago
Essentially, one could simply copy the .git folder to a web visible place: cp -r .git ~/public_html/foo.git
- HerraBRE 15y ago
  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.
  - vidarh 15y ago
    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...
zokier 15y ago
This may be obvious but you can pull with ssh directly from workstation to another.
- HerraBRE 15y ago
  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.
  - zokier 15y ago
    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.
  - Lexarius 15y ago
    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.
- primatology 15y ago
  Exactly! One of my favorite tricks. Any decent shared host can serve as a makeshift git repository.
derwildemomo 15y ago
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 ).
- HerraBRE 15y ago
  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.
  - viraptor 15y ago
    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?
    - HerraBRE 15y ago
      It depends on the project really, centralization has many advantages. I just thought being able to go fully distributed was a neat hack.
joiguru 15y ago
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.
- HerraBRE 15y ago
  That is exactly what PageKite does, you should try it. :-)
  - joiguru 15y ago
    I am hooked :)

46 points by HerraBRE 15y ago

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

SaltwaterC 15y ago

Does it use Smart HTTP Transport? http://progit.org/2010/03/04/smart-http.html http://progit.org/2010/03/04/smart-http.html

judofyr 15y ago

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

HerraBRE 15y ago
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

beza1e1 15y ago

Essentially, one could simply copy the .git folder to a web visible place: cp -r .git ~/public_html/foo.git

HerraBRE 15y ago
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.
- vidarh 15y ago
  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...

zokier 15y ago

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

HerraBRE 15y ago
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.
- zokier 15y ago
  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.
- Lexarius 15y ago
  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.
primatology 15y ago
Exactly! One of my favorite tricks. Any decent shared host can serve as a makeshift git repository.

derwildemomo 15y ago

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 ).

HerraBRE 15y ago
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.
- viraptor 15y ago
  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?
  - HerraBRE 15y ago
    It depends on the project really, centralization has many advantages. I just thought being able to go fully distributed was a neat hack.

joiguru 15y ago

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.

HerraBRE 15y ago
That is exactly what PageKite does, you should try it. :-)
- joiguru 15y ago
  I am hooked :)