, so excluding this)
* If the two first conditions are fulfilled, is there anything I could
do to help this transition? (including helping Brian if his work hasn't
actually ended yet)
Sorry for bringing up again a subject that seems to be quite recurrent,
and for this long block of text,
Leo
Hello,
tl;dr: Is there currently a way to have fetch hooks, and if not do you
think it could be a nice feature?
I was in the process of implementing hooks for git that ensure the
repository is always cleanly signed by someone allowed to by the
repository itself. I think I've completed the signatu
On 02/07/2018 11:51 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Feb 07 2018, Leo Gaspard jotted:
>
>> Hello,
>>
>> tl;dr: Is there currently a way to have fetch hooks, and if not do you
>> think it could be a nice feature?
>>
>> I was in the proc
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 th
On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> 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
On 02/08/2018 06:02 PM, Leo Gaspard wrote:
> On 02/08/2018 04:30 PM, Joey Hess wrote:
>> [...]
>
> 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
g said, what do you think about these patches?
Thanks for your time!
Leo Gaspard
modifications here are heavily based on prior work by Joey Hess.
Based-on-patch-by: Joey Hess
Signed-off-by: Leo Gaspard
---
Documentation/githooks.txt | 37 +++
builtin/fetch.c | 210 +++-
t/t5574-fetch-tweak-fetch-hook.sh | 90
still
succeeding.
fetch_refs returns a refs_result, so that it can modify the ref_map.
Based-on-patch-by: Joey Hess
Signed-off-by: Leo Gaspard
---
builtin/fetch.c | 68 +
1 file changed, 44 insertions(+), 24 deletions(-)
diff --git a/builtin/fetc
On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> 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 ref
On 02/09/2018 11:30 PM, Jeff King wrote:
> On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> One thing that's not discussed yet, and I know just enough about for it
>> to tingle my spidey sense, but not enough to say for sure (CC'd Jeff &
>> Brandon who know more) is that
On 02/10/2018 01:13 AM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:
>> So the changes that are required are:
>> * Adding a notification-only post-fetch hook
>> * For handling tags, there is a need to have a refmap for tags. Maybe
On 02/10/2018 02:08 AM, Junio C Hamano wrote:
> Leo Gaspard writes:
>
>> On 02/10/2018 01:13 AM, Jeff King wrote:
>>> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:
>>>> So the changes that are required are:
>>>> * Adding a notificati
On 02/10/2018 02:33 AM, Leo Gaspard wrote:> I guess the very early part
of the discussion you're speaking of is what
> I was assuming after reading
> https://marc.info/?l=git&m=132478296309094&w=2
>
> [...]
>
> So the reason for a post-fetch in my opini
On 02/10/2018 01:21 PM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote:
>
>>> Yeah, tag-following may be a little tricky, because it usually wants to
>>> write to refs/tags/. One workaround would be to have your config look
>>> lik
On 02/12/2018 08:23 PM, Brandon Williams wrote:> Maybe this isn't
helpful but you may be able to implement this by using
> a remote-helper. The helper could perform any sort of caching it needed
> to prevent re-downloading large amounts of data that is potentially
> thrown away, while only sending
On 02/14/2018 02:35 AM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 07:36:47PM +0100, Leo Gaspard wrote:
>> [...]
> I think there may have been some more concrete proposals after that, but
> that's what I was able to dig up quickly.
Thanks! Though it looks way above my knowle
On 02/19/2018 10:23 PM, Jeff King wrote:
> [...]
> If you do go this route, please model it after "pre-receive" rather than
> "update". We had "update" originally but found it was too limiting for
> hooks to see only one ref at a time. So we introduced pre-receive. The
> "update" hook remains for h
On 02/20/2018 08:42 AM, Jeff King wrote:>> [...]
>>
>> Is there a way for “pre-receive” to individually filter [refs]? I was
>> under the impression that the only way to do that was to use the
>> “update” hook, which was the reason I wanted to model it after “update”
>> rather than “pre-receive” (m
19 matches
Mail list logo
