2014/09/19 5:27 "lee" <lee@yun.yagibdah.de>:
>
> Joel Rees <joel.rees@gmail.com> writes:
>
> > 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:
> >>>
> >>> 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
> >
> > ?
>
> In one case, I cloned it; in another, I don't know anymore what exactly
> I did.
This is something you really need to understand. I strongly encourage you to dig into it.
> > I think git is the usual/default protocol when you clone a repository.
>
> I don't know --- look at an arbitrary repo on github, and you'll find
> yourself presented with an http URL to clone it. Look at the emacs
> git-repo, and you're presented a git URL to clone it.
You know, I don't use github. I just checked what they offer, and it looks like the web interface is optimized for web based use, which makes sense. But web-based is by no means the only interface.
On sourceforge, I do use the web-based interface for checking diffs between pushes to the sourceforge repositories I use. Those don't really tell me anything about activity on other repositories, including my own.
> Whether that means that all repos are accessible through http _and_ git,
> I don't know.
I would be really surprised if github didn't make their repositories available through git protocol.
> > Or do you mean that you are using a web browser to browse and observe
> > the repository?
>
> Yes and no. With one of the repos, it's convenient to use a web browser
> to look at the change log because it's presented on the web site. To
> figure out if there have been changes, I'd have to look at the web
> site.
>
> In the other case, I'm not looking at a web site.
>
> In any of the cases, I'm *not* being informed about new commits. I need
> to look for them one way or another, and I'd rather get an email that
> informs me automatically.
If git status is not telling you about pushes to the repositories you are accessing, you've got your HEAD set to something else, maybe a branch point or a historical point.
> > 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.
>
> On of the repos is an upstream repo to my fork, so I pull from it from
> time to time. The other one is the emacs repo, and I haven't made a
> fork of it. I just pull from it from time to time to keep my emacs
> version up to date --- and I have made a modification to hilock.el of
> which I hope might be integrated plus a minor modification to one of the
> files written in C. That can make things a bit more complicated than
> simply pulling every now and then.
>
> All of this may involve the whole tree or not, depending on what has
> changed. What does it matter?
I had the idea that maybe you were just interested in the activity, not in the resulting code, which I see is not the case.
> >> 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.
>
> Probably not --- we'd have to ask the developers of git why such an
> important feature is missing.
There are some that do. The hooks are available to the repository adminstrators in git.
> > 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.
>
> How would that work, or why would they make a copy at some point in
> time, work totally isolated on that for a year or for many years and
> only then look at a central repo eventually? That doesn't make any
> sense to me.
Years or days, or minutes, which you consider central is your choice. Shifting your HEAD to a different repository does require a bit of work in merging code, but the repository doesn't really care.
> Git is supposed to be a tool for collaboration, isn't it? People
> working together on something would probably have a hard time to
> collaborate through isolating themselves by not keeping track of a
> central repo or by not keeping track of everyone elses repo.
When they say git is for de-centralized collaboration, they mean it.
Well, you do have to make choices about which repository you set as HEAD at any particular point in time.
> Once someone pushes to the central repo (or their own),
There is no central other than the one you specify. And you don't push to your own (unless you decided to keep a local "central" of your own, separate from your working copy). You commit into your working repository and then push your commits to wherever you are pushing them to when you think it's time to push them outside your working copy.
> everyone else
> may want to have the latest version
Actually, not necessarily. Generally, you decide when to merge code on criteria of your own. You often don't want the latest, and you may in fact want to keep your head pointed a bit behind the latest as a matter of practice.
> and thus needs to pull --- or they
> decide to wait when looking at the change log. How does everyone get
> informed about new commits (when a hook that sends out an email isn't
> used)?
git status
git diff
and setting the appropriate head between issuing either.
> Everyone would have to track the centralised repo, or various repos, by
> manually using a web browser or some other manual means to see what's
> going on. It's stupid when you have to do that.
Well, setting aside the web browser comment, perhaps what you are missing is that git makes such manual specification of what you are comparing your code to relatively easy, maybe so easy that you accidentally set your head back off the latest without knowing that's what you did. And it will remain set there until you set it again, which is the reason diffs, status , and even pulls don't see any changes.
At least, that's my best guess about what's happening for you.
Joel Rees
Computer storage is just fancy paper, and the CPU is just a fancy pen.
All is text, flowing from the past into the future forever.