git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Matt McCutchen <matt@mattmccutchen.net>,
	git@vger.kernel.org, Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCH 1/2] gitweb: allow access to forks with strict_export
Date: Sat, 13 Dec 2008 14:31:08 -0800	[thread overview]
Message-ID: <7vr64b4sib.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <m3prjvg2st.fsf@localhost.localdomain> (Jakub Narebski's message of "Sat, 13 Dec 2008 13:53:26 -0800 (PST)")

Jakub Narebski <jnareb@gmail.com> writes:

> Matt McCutchen <matt@mattmccutchen.net> writes:
>
> CC-ed Petr Baudis, author of forks support in gitweb.
>
>> git_get_projects_list excludes forks in order to unclutter the main
>> project list, but this caused the strict_export check, which also relies
>> on git_get_project_list, to incorrectly fail for forks.  This patch adds
>> an argument so git_get_projects_list knows when it is being called for a
>> strict_export check (as opposed to a user-visible project list) and
>> doesn't exclude the forks.
>>
>> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
>
> Looks good for me.

That sounds like a broken API to me.

At least, please have the decency to not call the extra parameter "for
strict export".  I would understand it if the extra parameter is called
"toplevel_only" (or its negation, "include_forks").

IOW, don't name a parameter after the name of one caller that happens to
want an unspecified special semantics, without saying what that special
semantics is.  Instead, name it after the special semantics that the
argument triggers.

  reply	other threads:[~2008-12-13 22:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-13 21:16 [PATCH 1/2] gitweb: allow access to forks with strict_export Matt McCutchen
2008-12-13 21:53 ` Jakub Narebski
2008-12-13 22:31   ` Junio C Hamano [this message]
2008-12-13 22:51     ` Jakub Narebski
2008-12-14  2:06       ` Matt McCutchen
2008-12-20  0:35         ` Jakub Narebski
2008-12-14  1:51     ` Matt McCutchen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr64b4sib.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=matt@mattmccutchen.net \
    --cc=pasky@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).