Re: git: how to figure out with a script what the last commit on remote repo is without fetching it
On 08/09/14 15:10, lee wrote:
> Rusi Mody <rustompmody@gmail.com> writes:
>
>> On Monday, September 8, 2014 4:20:02 PM UTC+5:30, lee wrote:
>>> Jonathan Dowland writes:
>>
>>>> On Sat, Sep 06, 2014 at 12:04:44AM +0200, lee wrote:
>>>>> how would I figure out what the last commit to a remote repo was without
>>>>> first fetching or pulling the remote repo?
>>>> This is an interesting question and I don't know the answer to it, perhaps it
>>>> is not yet possible. However, you might be able to solve the problem you have
>>>> in a different way: do you have write access to the remote repository? If so,
>>>> you should look into installing a post-update hook which will email you upon
>>>> commits being made to that repository.
>>
>>> Unfortunately, I don't have write access to the remote repos I want to
>>> be informed about.
>>
>>> Perhaps there's a mailing list for git ... If it turns out that what
>>> I'm trying isn't possible, I'll make feature request.
>>
>> This is a nice list to ask:
>> https://groups.google.com/forum/#!forum/git-users
>
> How would I subscribe to this list?
>
>> However I dont think this is a reasonable thing to ask
>
> What is unreasonable about wanting to get informed automatically about
> the existence of new commits without having to go to unreasonable
> lengths to obtain this information?
>
>> [I must be missing something but...]
>> It seems analogous to this scenario:
>> I phone you at (your) 6 am and ask "Lee are you awake?"
>> If you answer, you are awake.
>> But I want to find out without waking you... Is that possible/feasible?
>> [As I said I must be missing something]
>
> Yes, you're missing that:
>
>
> + because I don't want to be woken up by arbitrary phone calls at
> unreasonable times, you are put into a waiting loop which stalls you
> for an unpredictable amount of time when you call me, with an
> undetermined risk that I might somehow get access to your brain and
> reprogram it without your knowledge via this connection
>
> + you don't know whether I'm awake or not when I don't answer or when
> you do or don't get into the waiting loop
>
> + if you get beyond the waiting loop, you have to receive unpredictable
> amounts of data which you need to somehow examine in order to
> determine whether I'm awake or not
>
>
> I suppose you'd be looking for something like an immediate, direct
> answer which is simply either "yes" or "no", wouldn't you?
>
> Differently put, you don't need to wake me up because the information
> you're looking for is already available automatically: I have a sensor
> in my bed which detects my sleep-status and puts a file telling you the
> status onto my web server.
>
> The problem is that you can't just get the information when you connect to my
> web server because you need to:
>
>
> + download all the files I might have on it (which can currently be
> up to half a terrabyte, but you don't know this)
>
> + go through that half terrabyte (or how much it has actually been) of
> data and somehow find out what my sleep-status is
>
>
> This is what I'm calling "unreasonable lengths" and what I'm trying to
> avoid having to do when figuring out if there have been new commits to a
> git repo.
>
> 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.
If he hasn't done that, then you could try asking him to do so; it's not
git's problem. But then, perhaps, the repository owner doesn't want to
publish that data, for whatever reason. Git will respect that choice.
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England |
Reply to: