Tony van der Hoff <t...@vanderhoff.org> writes: >> Why can't I simply ask the (server of the) remote repo "when/what was >> the last commit?". Why should I have to transfer large or huge amounts >> of data to get an information which doesn't need to take more than 4 >> bytes (i. e. a unix timestamp)? >> >> > It seems to me that you're approaching this from the wrong end. > > What you're asking for is very easily set up by the repository owner, by > setting git up to emit an email to (say) a mailing list after each > commit/recieve/update, by configuring a hook.
That would probably be better than a potentially large number of people polling the repo to find out about new commits. > If he hasn't done that, then you could try asking him to do so; it's not > git's problem. I don't even know who the owner is, and I haven't seen any information saying that I could subscribe to a mailing list to be notified about commits. Gits' problem is that there's no simple and reliable way to find out about new commits when the repo is not set up to publish this information by itself. > But then, perhaps, the repository owner doesn't want to publish that > data, for whatever reason. Git will respect that choice. The repo can be cloned and fetched from by anyone. Saying that its owner might not want to publish new commits doesn't exactly apply in this case because data about new commits is already being published that way. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761gx9a5l....@yun.yagibdah.de
