All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: lbdyck@gmail.com
Cc: 'Junio C Hamano' <gitster@pobox.com>,
	'Sean Allred' <allred.sean@gmail.com>,
	git@vger.kernel.org
Subject: Re: git client enhancement request
Date: Mon, 13 May 2024 21:19:51 +0000	[thread overview]
Message-ID: <ZkKD95VBlmsUJdB5@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <051d01daa567$caa22750$5fe675f0$@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

On 2024-05-13 at 19:00:14, lbdyck@gmail.com wrote:
> I have to interject here that the git client doing a push must be fully
> authenticated which implies to me that all the information required is
> available to do so and allow the server repository to be updated.

First of all, the authentication required to _create_ a repository need
not be the same as to _read_ or _write_ a repository.  It might require
a totally different set of scopes or privileges to create a new
repository, which many users will have avoided giving to their
credentials for least-privilege reasons.

Second, there's no standard API to perform that functionality, and the
implementation varies widely on different forges.  There are also people
who don't use forges at all, or use tooling like gitolite[0] that handles
this differently.  Adding such functionality into the Git protocol
requires intertwining that functionality and the services that provide
it with the standard forge API, so it's likely to be very complex for
forges to implement using the same functionality as Git uses currently.

Third, we specifically try not to prioritize any individual piece of
software or project here.  Even if there are many common forges, we
won't ship tooling that's specific to GitHub, GitLab, or Bitbucket,
since that prioritizes those users over others.  Since there's no
standard API for this, we won't be adding any forge-specific
functionality to Git.

Even if we decided to implement a standard API for doing this, it
doesn't mean that forges would adopt it.  Many forges don't implement
`git-archive` over SSH, for example, since it's hard to cache versus
using HTTP.

[0] gitolite actually allows you to create repositories by just pushing
to them if you have permissions to do so in the configuration.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2024-05-13 21:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-13 15:07 git client enhancement request lbdyck
2024-05-13 17:56 ` Sean Allred
2024-05-13 18:02   ` lbdyck
2024-05-13 18:51   ` Junio C Hamano
2024-05-13 19:00     ` lbdyck
2024-05-13 21:19       ` brian m. carlson [this message]
2024-05-13 19:09   ` rsbecker
2024-05-13 19:11     ` lbdyck

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=ZkKD95VBlmsUJdB5@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=allred.sean@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lbdyck@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.