Re: Fetch-hooks

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 8, 2018, 21:06 UTC
Message-ID: <87bmgzmbsk.fsf@evledraar.gmail.com>
In-Reply-To: <871af155-a159-2a29-2e48-74e7a98b60d4@gaspard.io>

On Thu, Feb 08 2018, Leo Gaspard jotted:

Show 31 quoted lines

> On 02/08/2018 04:30 PM, Joey Hess wrote:
>> Leo Gaspard wrote:
>>> That said, I just came upon [1] (esp. the description [2] and the patch
>>> [3]), and wondered: it looks like the patch was abandoned midway in
>>> favor of a hook refactoring. Would you happen to know whether the hook
>>> refactoring eventually took place, and/or whether this patch was
>>> resubmitted later, and/or whether it would still be possible to merge
>>> this now? (not having any experience with git's internals yet, I don't
>>> really know whether these are stupid questions or not)
>>>
>>> PS: Cc'ing Joey, as you most likely know best what eventually happened,
>>> if you can remember it?
>>
>> I don't remember it well, but reviewing the thread, I think it foundered
>> on this comment by Junio:
>>
>>> That use case sounds like that "git fetch" is called as a first class UI,
>>> which is covered by "git myfetch" (you can call it "git annex fetch")
>>> wrapper approach, the canonical example of a hook that we explicitly do
>>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> not want to add.
>>   ^^^^^^^^^^^^^^^
>>
>> While I still think a fetch hook would be a good idea for reasons of
>> composability, I then just went off and implemented such a wrapper for
>> my own particular use case, and the wrapper program then grew to cover
>> use cases that a hook would not have been able to cover, so ...
>
> Hmm, OK, so I guess I'll try to update the patch when I get some time to
> delve into git's internals, as my use case (forbidding some fetches)
> couldn't afaik be covered by a wrapper hook.

Per my reading of https://public-inbox.org/git/20111224234212.GA21533@gnu.kitenet.net/ what Joey implemented is not what you described in your initial mail.

His is a *post*-fetch hook, we've already done the fetch and are just telling you as a courtesy what refs changed. You could also implement this as some cronjob that polls git for-each-ref but it's easier as a hook, fine.

What you're describing is something like a pre-fetch hook analogous to the pre-receive hooks, where you're fed refs updated on the remote on stdin, and can say you don't want some of those to be updated.

This may just be a lack of imagination on my part, but I don't see how that's sensible at all.

The refs we fetch are our *copy* of the remote refs, why would you not want to track the upstream remote. You're going to refuse some branches and what? Be further behind until some point in the future where the tip is GPG-signed and you accept it, at which poich you'll need to do more work than if you were up-to-date with the almost-GPG-signed version?

I think you're confusing two things here. One is the reasonable concern of wanting to not have your local copy of remote refs have undesirable content, but a pre-fetch hook is not the way to accomplish that.

The other is e.g. to ensure that you never locally check out some "bad" ref, we don't have hook support for that, but could add it, e.g. git-checkout and git reset --hard could be taught about some pre-checkout hook.

You could also have some intermediate step between these two, where e.g. your refspec for "origin" is "+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default "+refs/heads/*:refs/remotes/origin/*", you fetch all refs to that location, then you move them (with some alias/hook) to "refs/remotes/origin/*" once they're seen to be "OK".