Re: git: how to figure out with a script what the last commit on remote repo is without fetching it
On Sun, Sep 14, 2014 at 10:43 PM, lee <lee@yun.yagibdah.de> wrote:
> Joel Rees <joel.rees@gmail.com> writes:
>
>> 2014/09/14 6:55 "lee" <lee@ <lee@yun.yagibdah.de>yun.yagibdah.de
>> <lee@yun.yagibdah.de>>:
>>>
>>> Joel Rees <joel.rees <joel.rees@gmail.com>@ <joel.rees@gmail.com>gmail.com
>> <joel.rees@gmail.com>> writes:
>>>
>>> > 2014/09/12 3:35 "lee" <lee@ <lee@yun.yagibdah.de>yun.yagibdah.de
>> <lee@yun.yagibdah.de>>:
>>> >>
>>> >> [...]
>>> >> Well, I don't want to program some sort of meta-git ... I merely want
>> a
>>> >> simple way to be informed about new commits.
>>> >
>>> > I'm still wondering whether a cron job that does a status request on the
>>> > head in question wouldn't be good enough.
>>>
>>> Like Jonathan suggested? That would probably work fine for what I'm
>>> doing with the repos reachable via https.
>>
>> I can't think of any reason it would be dependent on https connectivity.
>> Any way you can reach the repository should allow scripted query, thus
>> checking by a cron job.
>
> Oh I don't think it's limited; the problem is to figure out how to use
> other protocols like git to get the information.
Hmm. So. When you do a
git status
on the command line, with the current working directory at the
appropriate place in the repostory, you have taken the trouble to
specify your repository as something like
http://git.code.sf.net/p/asm68c/code
instead of
git://git.code.sf.net/p/asm68c/code
?
I think git is the usual/default protocol when you clone a repository.
Or do you mean that you are using a web browser to browse and observe
the repository? If so,suddenly your questions make sense, sort of.
Except I then want to know why you want to access the repository, if
you aren't doing things that involve the whole tree, or perhaps
sub-sections of the tree.
>>> > I don't recall svn or cvs doing this without using a hook, either, even
>>> > though a commit does mean something else there.
>>>
>>> I suspect that the makers of these systems might not want users to pull
>>> the information and thus decided not to implement a feature that allows
>>> to get it in some easy way ...
>>
>> I know svn has such hooks.
>
> Git does, too. The difference is that when you set up a hook to, say,
> send an email to some users, this doesn't burden the server as much as
> when you have lots of people connecting all the time to poll
> information. The email is sent in one go, and its delivery can be
> offloaded to an MTA that sends it to 50k users or so within its own
> time.
>
> With polling, these 50k users each connecting three times a day makes
> 150k connections to the git server. The git server would have to be
> able to completely handle each connection within 0.576 seconds, and it
> might become unreachable during spikes.
Well, yeah, that's one of the reasons the hooks have been provided.
But most repositories don't have that kind of traffic.
Uhm, I think the kernel is going to be something like a thousand
users. When you have a lot of heavy lifting going on, yeah, you'll
likely have spikes, but that's what building retries into the
protocols is for. And you should also consider that, with git, the
assumption is that everyone is mostly working on their own clone of
the repository, sometimes doing diffs and so-forth with other
developers' repositories, and only occasionally going to a central
repository.
Sourceforge, yeah sourceforge has that kind of traffic, and worse, but
they use some really sophisticated load-balancing magic to distribute
the hits, and most of the projects are mostly idle anyway. I've never
seen sourceforge become unreachable. Take a minute or two to respond
to a push (git) or commit (svn/cvs), yes. That's more often because
the code I'm accessing is off in some low-speed store at the moment.
Unreachable, no.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Reply to: