Pingback/Trackback for Git?

Pingback/Trackback for Git?

[Thomas Perl]

Hello, Git users and developers!

I've been thinking about having some kind of pingback/trackback
support for Git repositories the same way pingback/trackback exist for
blogs. Apart from having a list of repository mirrors, it also allows
a developer to see a list of repositories from the same codebase.

I've outlined some ideas here, feel free to suggest implementations or
point out problems:

http://tperl.blogspot.com/2007/07/pingbacktrackback-for-git.html


Thanks,
Thomas

Re: Pingback/Trackback for Git?

[Junio C Hamano]

"Thomas Perl" <th.perl@gmail.com> writes:

> I've outlined some ideas here, feel free to suggest implementations or
> point out problems:
>
> http://tperl.blogspot.com/2007/07/pingbacktrackback-for-git.html

It was unclear to me who does what and when in the overall
picture you envision after reading that page.  You seem to
assume there is a prominent ping/trackback repository that
everybody who is interested looks at.  Who updates it?  When?
With what?  How does the namespace inside that repository
managed, if managed in any way?  Given a project name, how does
one learn which pick/grackback repository (and perhaps which
branch) to go to to learn the current status about it?

Re: Pingback/Trackback for Git?

[Thomas Perl]

Hello, Junio!

2007/7/4, Junio C Hamano <gitster@pobox.com>:
> It was unclear to me who does what and when in the overall
> picture you envision after reading that page.  You seem to
> assume there is a prominent ping/trackback repository that
> everybody who is interested looks at.  Who updates it?  When?
> With what?  How does the namespace inside that repository
> managed, if managed in any way?  Given a project name, how does
> one learn which pick/grackback repository (and perhaps which
> branch) to go to to learn the current status about it?

Every repository keeps track of the pingbacks it receives. The
simplest way of storing all pingbacks would be a simple text file that
lists one repository per line in a URL, i.e.

http://git.server.com/repos/game.git
git://mirrors.git-hosting.com/ga/game.git
http://johnny.org/my-projects/game.git
http://universityx.edu/~bob/src/game.git

If a user clones a repository, it can copy this trackback list. Git
can also optionally use this list to fetch objects from multiple
servers to increase performance (imagine an upstream git:// repository
with a forked http:// repository that has packs, the client could use
the git:// repository for fetching as much single object as possible
and only using the forked repository for all objects not yet found in
the upstream repository).

Sending a pingback should append the pinging repository URL to the
pinged repository's list (see above). Before appending the URL, the
pinged repository should check if the URL exists and if there is a Git
repository at the given URL and if the pinging repository is based on
the pinged repository.

There is not a single repository with pingbacks/trackbacks, but every
repository has its own list of "related" repositories. So when I'm
interested in the repository from project at URL "X", I can fetch its
repository or only its mirror list and get a list of URLs that also
carry (derived) versions of the project at URL "X".

Of course, your idea with having a centralized repository (that only
stores URLs) would be nice when an upstream Git repository dies to
find some other repository where the data is still available:

1) Clone repository from URL "X"
2) 404 -- not found
3) Get list of mirrors from URL repository
4) Download repository from other URL

But that defeats some gains from a truly distributed vcs, so just
keeping track of a list of  URLs that cloned from this repository
should be enough.