Why various git commands are available only locally?

Question

The number of commands that you can run agains a remote repository using the standard clients is very limited.
Most of the remote commands are provided by git-ls-remote. Is this a limitation of the git client only or also of the git server?

I would like to write a client that provides most of the commands that you can run locally to be run on the remote repository too.

A good case for this would be to fetch the logs (i.e. git log) thus the reason of the question. The current practice is to use a proprietary API developed by whatever service is hosting the git repostiory (github, gitlab, gerrit, bitbucket, stash etc) so I think a client developed using the standard git protocol would sort out the this issue.

Why do you need to git log remotely? Just fetch the changes from the remote repo then log locally. http://stackoverflow.com/questions/13941976/commit-history-on-remote-repository — gman, May 31 '15 at 15:10
I don't want to clone/fetch the repo locally. I hope that makes sense. — The user with no hat, May 31 '15 at 15:16
@gman to clarify the comment, it would be inefficient to clone the repository so that I can get the log. I need only the log so I want just that. There are a number of proprietary APIs that fulfill this (github api, gitlab api, hulu api etc). If the git server provides the data I want to develop a client that puts these APIs out of business. — The user with no hat, May 31 '15 at 15:31
You don't have to clone the entire repository, just the branch whose log you want. — chepner, May 31 '15 at 15:53
This is entirely different from the purpose of the Git protocol. It could easily be done with full file access (e.g. through SSH) or could be done using a special remote client API. The purpose of Git protocol is just sharing packs of objects and their dependencies. — Pavel Šimerda, May 31 '15 at 16:09
@chepner let's pretend that I'm a bot without write file access. And yeah cloning just the branch is quite inefficient if all I want is only the commit messages. — The user with no hat, May 31 '15 at 16:26
@PavelŠimerda it could be the case but that's precisely what I'm trying to avoid, yet another API. If I'm moving to a SAAS provider (i.e. github) I need to use their custom made remote API and so on. — The user with no hat, May 31 '15 at 16:29
That is great yet it doesn't make Git protocol more useful for your purpose. In other words there is no well known standard solution for your use case. — Pavel Šimerda, May 31 '15 at 16:41

score 5 · Answer 1 · edited Jun 20 '20 at 09:12

I think a client developed using the standard git protocol would sort out the this issue.

That would revert the decentralized model of Git (where every operation is local and fast) to a centralized one (where you need to access a server to perform an operation.

Most of the commands (logs, diff, commit, ...) make sense when you have the full repo.

If the git server provides the data I want to develop a client that puts these APIs out of business.

There is no "git server", only listeners (httpd or sshd) which then call git-receive-pack and git-upload-pack (in case of the smart protocol).

^{(From "Reimplementing “git clone” in Haskell from the bottom up")}

That is why an API is developed on top of those listeners, in order to expose those commands (local to the repos managed by the hosting server).

One alternative I am aware of is the gitolite site local commands.
Gitolite is an authentication layer (called by the listener https or ssh, and checking the right of a user to access a repo).
It can delegate some commands to be executed "locally" on the server:

The main purpose of gitolite is to prevent you from getting a shell. But there are commands that you often need to run on the server (i.e., cannot be done by pushing something to a repo).

To enable this, gitolite allows the admin to setup scripts in a special directory that users can then run. Gitolite comes with a set of working scripts that your admin may install, or may use as a starting point for his own, if he chooses.

Think of these commands as equivalent to those in COMMAND_DIR in man git-shell.

Possible extension: see "Announcing GitTorrent: A Decentralized GitHub "

This is an example of getting from a Git server something else than just the pack files.

Using a different protocol can make a git clone return something else than the full repo:

git clone gittorrent://github.com/cjb/recursers

Git actually has an extensible mechanism for network protocols built in. The way it works is that my git clone line gets turned into “run the git-remote-gittorrent command and give it the URL as an argument”.

Unfortunately I'm trying to avoid installing additional software. That's because I was looking for a "standard" solution which works both on different SAAS providers (i.e. github) and on my own git server. I was hoping that git-receive-pack and git-upload-pack is smart enough to provide the data I need to implement a client which could replace the various proprietary APIs/solutions that are currently available. — The user with no hat, May 31 '15 at 16:33
@Theuserwithnohat I understand. I don't think git-receive-pack and git-upload-pack can do anything else that return pack files. I have edited the answer to illustrate that a git protocol can be extended/redefined. But that means installing something else on the server. Git alone doesn't seem to support your use case. — VonC, May 31 '15 at 16:39

Why various git commands are available only locally?

1 Answers1