From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Marius Raht <mariusraht@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Feature Request: Check if commit is existent via http-protocol
Date: Thu, 14 Nov 2019 02:52:44 +0000 [thread overview]
Message-ID: <20191114025244.GC9216@camp.crustytoothpaste.net> (raw)
In-Reply-To: <c5147250-4af2-0e98-db6e-20602a38fba4@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
On 2019-11-13 at 13:14:00, Marius Raht wrote:
> Hi there,
>
> for the development of a git client on a SAP System we need to make sure
> that a specific commit is existent in a specific branch. For that we have to
> ask the git server for the related information via the http protocol. There
> are two option from my point of view to achieve this:
>
> 1) You can request a specific list of commits of a branch by index (e.g. "1
> to 30 <sha1 of branch>" would send the first 30 commits from the server to
> the client of the branch "master"
> 2) You send a request to the git server to verify that a specific commit is
> within a specific branch´and the response is something like "TRUE" or the
> sha1 of the branch the commit belongs to (branch of the time the commit was
> created).
I think there may be a misunderstanding of the design of the Git HTTP
protocol. It's essentially a stateless version of the regular Git
protocol which provides data transport (and as a side effect, ref
discovery). It isn't designed to be an API that can be queried
remotely, and so it intentionally supports an extremely limited set of
functionality.
Git supports a massive number of ways to query data, and there's just no
way to efficiently and securely support all of those methods natively
over an API. In fact, some operations Git can perform are potentially
expensive, and exposing an API to perform those is a security problem
(due to DoS attacks).
Some of that functionality is available in various Git hosting solutions
through their own APIs, but as far as I'm aware, there aren't any which
perform this operation (which is essentially "git merge-base
--is-ancestor"). If you want this functionality in a particular
platform, I'd encourage you to reach out to the provider of that
platform to ask them if they'd implement it. However, I don't think
we're likely to implement it in Git's HTTP protocol.
Other contributors are welcome to chime in if anything I said seems
incorrect or off base.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
next prev parent reply other threads:[~2019-11-14 2:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 13:14 Feature Request: Check if commit is existent via http-protocol Marius Raht
2019-11-14 2:52 ` brian m. carlson [this message]
2019-11-14 6:41 ` Jeff King
2019-11-14 20:05 ` Jonathan Tan
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=20191114025244.GC9216@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=mariusraht@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 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).