On Tue, 13 Dec 2016 21:44:15 -0800 (PST) essam Ganadily <doctore...@gmail.com> wrote:
> As far as i can tell, there is no way i can create remote git > repository from command line (git.exe in windows). if i am not > mistaken shall you tell me why such limitation exist given that git > is an old and mature project. [...] > for example "git create remote repo myreponame" could work nicely (it > return the clone urls) And what do you propose such command would do, precisely? I'm afraid you might be keeping a somewhat limited world-view about how Git is used in the wild -- possibly you're being a bit fixated on Github or some other popular proprietary Git hosting solution. The problem with your proposition is that is has no sensible way to work _in a general case_ due to at least the reasons outlined below. Out of the box, Git supports four ways to access remote repositories: - Directly accessing a filesystem (this one works when you use the file:// scheme in repo URLs or just plain /path/to/the/repo). - Over HTTP[S]. - Over SSH. - Over the native Git wire protocol (git:// scheme in the URLs). The first method is typically used on a local machine. Some people use it to host remote repositories on networked filesystems such as NFS and CIFS (SMB). The latter is typically used for fast no frills networked R/O access to a repositories considered OK to share (to the Internet or intranet). HTTP[S] and SSH are typically used for networked access where authentication is required -- at least for write (push) access. Note that in neither of those cases Git itself does any authentication or authorization: its designers deliberately deferred these tasks to front-ends mediating access to Git repositories. There, in the first case, your rights are controlled by your permissions on the tagret filesystem; in the case of HTTP[S] and SSH the authentication is performed (if any) by the corresponding HTTP and SSH servers, and the native bare Git protocol is either R/O or, when explicitly told to do so, is R/W for everyone who can reach your server via TCP. Now consider that there exist various Git hosting solutions -- ranging from reasonably low-level ones such as gitolite to "turn-key" solutions like Gitblit, Gitlab and certain commercial ones -- such as Atlassian Stash etc. All these solutions provide some _different_ means for administrative controlling of creation and maintaining of the Git repositories they host. The UI to do this differ greatly. Say, gitolite is controlled by modifying certain files in a special administrative Git repository and processing the changes committed into it when you push it up to gitolite. The "turn-key" solutions typically provide some "web" UI accessible via an Internet browser. Now consider that while on your local machine you're typically free to create and destroy your own Git repositories at will, the case with remote ones is different and is highly dependent on how and where they are hosted, as well as how they consider your disposition with regard to them. Say, I might keep some of my own remote repos on my own home server accessible via SSH. There, I have full permissions to do with those repositories whatever I wish. When I host them somewhere like Github, I also have sort-of full permissions on "my" space -- up to some quota limits, but still. The corporate setup, on the other hand, is way different: typically you can't create repositories at will; they are typically managed by a set of dedicated admins which create the repos on puspose, and the permissions on them are tightly controlled. There is usually no way for regular devs to create remote repositories at will (as there's typically no need for this anyway). Yet another case to consider is that remote repositories might have special policies enforced in them by the means of hooks (run the `git help hooks` command to get the idea). As you should see by now, the ways remote Git repositories are operated and accessed are too incoherent with each other. I think it could be possible to arm a Git wire protocol with a special commands "create a remote repo" and "delete this remote repo", teach the former to accept a list of options the `git init` command knows about etc. Git hosting front-ends could be made understand it, and Git itself could grow a new special command for creating a repo by request from the client. The problem, is that this command will cover only a fraction of the use-cases for a remote repository management, and I'm afraid this fraction won't be too large. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
