git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5 1/5] hiderefs: add hide-refs hook to hide refs dynamically

From
孙超 <16657101987@163.com>
Date
Sep 17, 2022, 08:14 UTC
Message-ID
<DBFEA215-476E-4D41-8B5F-C6080F883C9D@163.com>
In-Reply-To
<xmqq5yhni4uj.fsf@gitster.g>
Show 13 quoted lines
> On Sep 14, 2022, at 01:01, Junio C Hamano <gitster@pobox.com> wrote:
> 
>> Gerrit is implemented by JGit and is known as a centralized workflow system
>> which supports reference-level access control for repository. If we choose
>> to work in centralized workflow like what Gerrit provided, reference-level
>> access control is needed and we might add a reference filter hook
>> `hide-refs` to hide the private data.
> 
> Please rewrite the above so that it does not sound like "Gerrit
> supports it, there are tons of users of Gerrit, we must support it,
> too".  If this feature is meaningful for us, even if Gerrit folks
> were deprecating and planning to remove the support of it, we would
> add it.  If it is not, even if Gerrit folks support it, we wouldn't.
Hi Junio, thanks for your advice here, I cannot agree with you more, I will do it.
Show 12 quoted lines
> 
>> +
>> +		/*
>> +		 * the prefix 'hook:' means that the matched refs will be
>> +		 * checked by the hide-refs hook dynamically, we need to put
>> +		 * the 'ref' string to the hook_hide_refs list
>> +		 */
> 
> I am not sure if this deserves a five-line comment.  We didn't need
> to have a comment that says "value without hook: means the matched
> refs will be hidden and we need to remember them in the hide_refs
> string_list" for over 10 years after all.
Agree, and I will remove them.
Show 12 quoted lines
> 
>> +		if (skip_prefix(value, "hook:", &value)) {
>> +			if (!strlen(value))
>> +				return error(_("missing value for '%s' after hook option"), var);
> 
> I am not sure it is a good idea to special case an empty string,
> especially here at this point in the code flow.  There would be
> strings that cannot be a refname prefix (e.g. "foo..bar") and such a
> check is better done at the place where the accumuldated list of ref
> patterns are actually used.  If you are using prefix match, a value
> of an empty string here would be a very natural way to say "we pass
> all the refs through our hook".

Yes, this is a good advice. Previously I cannot pass all the refs through the new hook unless set two config items like:

         [transfer]
             hiderefs = hook:HEAD
             hiderefs = hook:refs
I thinks it is a good idea to use only one config item to replace them:
         [transfer] hiderefs = hook:
Show 19 quoted lines
> 
> By the way, how does the negated entry work with this new one?  For
> static ones,
> 
> 	[transfer] hiderefs = !refs/heads/
> 
> would hide everything other than refs/heads/ hierarchy, I suppose.
> Would we spell
> 
> 	[transfer] hiderefs = hook:!refs/heads/
> 
> or
> 
> 	[transfer] hiderefs = !hook:refs/heads/
> 
> to say "send everything outside the branches to hook"?  If the
> former, you'd also need to special case "!" the same way as you
> special case an empty string (in short, I am saying that the special
> case only for an empty string does not make much sense).

In my patch I put the "!" after the "hook:", and negate passing all the refs to the hook would like

         [transfer] hiderefs = hook:!

however according to the match mechanism of hiderefs, it will be better to delete the config item above. If there are no config item, the hook will not be called.

So if I want to pass all the refs but some scope of them, it will be like (use a empty string to match all the refs)

         [transfer]
             hiderefs = hook:
             hiderefs = hook:!refs/pull/
which means pass all the refs except for the ones begins with 'refs/pull/'
> How does this mechanism work with gitnamespaces (see "git config --help"
> and read on transfer.hideRerfs)?

In my patch Git will send refname and refnamefull(with namepsace) to the hook, the hook will check it and response with 'hide' or not. In the following example, the letter 'G' stands for 'git-receive-pack' or 'git-upload-pack' and the letter 'H' stands for this hook

       # Send reference filter request to hook
       G: PKT-LINE(ref <refname>:<refnamefull>)
       G: flush-pkt
       # Receive result from the hook.
       # Case 1: this reference is hidden
       H: PKT-LINE(hide)
       H: flush-pkt
       # Case 2: this reference can be advertised
       H: flush-pkt

I'm not sure if it is suitable or not, I think it will be better to send both the refname and the refnamefull to the hook.

Show 15 quoted lines
> That's a somewhat duplicated code.  I wonder
> 
> 	/* no need for "hook" variable anymore */
> 	struct string_list **refs_list= &hide_refs;
> 
> 	if (strip "hook:" prefix from value)
> 		refs_list = &hook_hide_refs;
> 		...
> 	if (!*refs_list) {
>        	*refs_list = xcalloc(1, sizeof(*refs_list));
> 		(*refs_list)->strdup_strings = 1;
> 	}
> 	string_list_append(*refs_list, ref);
> 		
> would be a better organization.  I dunno.
Agree, it looks better, I will do it.
Show 10 quoted lines
> 
>> +
>> +	/*
>> +	 * Once hide-refs hook is invoked, Git need to do version negotiation,
>> +	 * with it, version number and process name ('uploadpack' or 'receive')
>> +	 * will send to it in pkt-line format, the proccess name is recorded
>> +	 * by hide_refs_section
>> +	 */
> 
> Grammar.
Will fix.
Show 13 quoted lines
> On Sep 17, 2022, at 01:52, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Junio C Hamano <gitster@pobox.com> writes:
> 
> ... ...
> 
>> +	if (hook && hide_refs_section.len == 0)
>> +		strbuf_addstr(&hide_refs_section, section);
>> +
> 
> that is only set inside the body of the if statement of the first
> conditional that ensures that we are reading *.hiderefs variable,
> but it would make more sense to move it inside it.
Agree, it will be better to move it inside.
Show 30 quoted lines
> 
> Or even better would be to clean the function up with a preliminary
> patch to return early when we are not looking at *.hiderefs variable,
> perhaps like the attached, and then build on top.
> 
> ... ...
> 
> +
> +	/*
> +	 * "section" is either "receive" or "uploadpack"; are we looking
> +	 * at transfer.hiderefs or $section.hiderefs?
> +	 */
> +	if (strcmp("transfer.hiderefs", var) &&
> +	    !(!parse_config_key(var, section, NULL, NULL, &key) &&
> +	      !strcmp(key, "hiderefs")))
> +		return 0; /* neither */
> +	if (!value)
> +		return config_error_nonbool(var);
> +	ref = xstrdup(value);
> +	len = strlen(ref);
> +	while (len && ref[len - 1] == '/')
> +		ref[--len] = '\0';
> +	if (!hide_refs) {
> +		CALLOC_ARRAY(hide_refs, 1);
> +		hide_refs->strdup_strings = 1;
> 	}
> +	string_list_append(hide_refs, ref);
> +
> 	return 0;
> }
Thanks for the advice here, I Will do it.
Previous: Junio C HamanoNext: Sun Chao via GitGitGadget
Message 32 of 42 in “refs-advertise: add hook to filter advertised refs”
  1. 0/3 refs-advertise: add hook to filter advertised refsSun Chao via GitGitGadget, Aug 3, 2022
  2. 1/3 refs-advertise: add hook to filter advertised refsSun Chao via GitGitGadget, Aug 3, 2022
  3. 3/3 doc: add documentation for the refs-advertise hookSun Chao via GitGitGadget, Aug 3, 2022
  4. 2/3 t1419: add test cases for refs-advertise hookSun Chao via GitGitGadget, Aug 3, 2022
  5. Junio C HamanoAug 3, 2022
  6. 孙超Aug 4, 2022
  7. Jiang XinAug 10, 2022
  8. 孙超Aug 10, 2022
  9. 0/3 hide-refs: add hook to force hide refsSun Chao via GitGitGadget, Aug 15, 2022
  10. 1/3 hide-refs: add hook to force hide refsSun Chao via GitGitGadget, Aug 15, 2022
  11. 2/3 t1419: add test cases for hide-refs hookSun Chao via GitGitGadget, Aug 15, 2022
  12. 3/3 doc: add documentation for the hide-refs hookSun Chao via GitGitGadget, Aug 15, 2022
  13. Eric SunshineAug 15, 2022
  14. 孙超Aug 15, 2022
  15. Junio C HamanoAug 15, 2022
  16. 0/3 hide-refs: add hook to force hide refsSun Chao via GitGitGadget, Aug 15, 2022
  17. 1/3 hide-refs: add hook to force hide refsSun Chao via GitGitGadget, Aug 15, 2022
  18. 3/3 doc: add documentation for the hide-refs hookSun Chao via GitGitGadget, Aug 15, 2022
  19. 2/3 t1419: add test cases for hide-refs hookSun Chao via GitGitGadget, Aug 15, 2022
  20. 0/3 hide-refs: add hook to force hide refsSun Chao via GitGitGadget, Aug 15, 2022
  21. 3/3 doc: add documentation for the hide-refs hookSun Chao via GitGitGadget, Aug 15, 2022
  22. 1/3 hide-refs: add hook to force hide refsSun Chao via GitGitGadget, Aug 15, 2022
  23. Junio C HamanoAug 15, 2022
  24. 孙超Aug 16, 2022
  25. Calvin WanAug 18, 2022
  26. 孙超Aug 19, 2022
  27. 2/3 t1419: add test cases for hide-refs hookSun Chao via GitGitGadget, Aug 15, 2022
  28. 0/5 hiderefs: add hide-refs hook to hide refs dynamicallySun Chao via GitGitGadget, Sep 9, 2022
  29. 1/5 hiderefs: add hide-refs hook to hide refs dynamicallySun Chao via GitGitGadget, Sep 9, 2022
  30. Junio C HamanoSep 13, 2022
  31. Junio C HamanoSep 16, 2022
  32. 孙超Sep 17, 2022
  33. 2/5 hiderefs: use new flag to mark force hidden refsSun Chao via GitGitGadget, Sep 9, 2022
  34. 3/5 hiderefs: hornor hide flags in wire protocol V2Sun Chao via GitGitGadget, Sep 9, 2022
  35. 4/5 test: add test cases for hide-refs hookSun Chao via GitGitGadget, Sep 9, 2022
  36. 5/5 doc: add documentation for the hide-refs hookSun Chao via GitGitGadget, Sep 9, 2022
  37. 0/5 hiderefs: add hide-refs hook to hide refs dynamicallySun Chao via GitGitGadget, Sep 20, 2022
  38. 1/5 hiderefs: add hide-refs hook to hide refs dynamicallySun Chao via GitGitGadget, Sep 20, 2022
  39. 3/5 hiderefs: hornor hide flags in wire protocol V2Sun Chao via GitGitGadget, Sep 20, 2022
  40. 2/5 hiderefs: use a new flag to mark force hidden refsSun Chao via GitGitGadget, Sep 20, 2022
  41. 5/5 doc: add documentation for the hide-refs hookSun Chao via GitGitGadget, Sep 20, 2022
  42. 4/5 test: add test cases for hide-refs hookSun Chao via GitGitGadget, Sep 20, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.