CODEWITHSUNDEEP
gitgithubversion-controldvcsvcs-checkout
the_thing
the_thing

Reputation: 1

How does version control systems recieve files from Git?

I want to know how does a VCS (Github for example) updated the database based on commits upstream? and how does git push send files to the VCS?

Thanks in advance!

Upvotes: -2

Views: 51

Answers (2)

Guildenstern
Guildenstern

Reputation: 3754

For Git, specifically git-push(1): the server must support the protocol version that the client (you) are using. Currently seems to be v0, v1, and v2 (or the last one might be in progress). Then they must support either the “Git protocol” URL (git://), HTTP, HTTPS, or SSH. I.e. this depends on the URL that you are using.

Objects and refs (e.g. branches) are sent over the wire (e.g. HTTPS) and the server stores them in the server repository. Git documents the protocols and everything. See for example:

  • gitprotocol-capabilities(5)
  • gitprotocol-common(5)
  • gitprotocol-http(5)
  • gitprotocol-pack(5)
  • gitprotocol-v2(5)

Upvotes: 0

torek
torek

Reputation: 487725

I'm not sure you are aware of how big a question it is that you are asking here. 😀

As phd noted in a comment, GitHub is not Git itself: github.com is the name for a hosting site that provides Git repository storage plus a lot of add-on features. The two other big ones out there today are Bitbucket and GitLab, and there are no doubt many smaller ones. Git—at least the original C implementation—is a suite of tools that implement a version control system, and defines a set of protocols for communications and file formats as well. Other implementations (JGit, Go-Git, and so on) use these same protocols and file formats as well.

[H]ow does a [hosting service] update the database based on commits upstream?

It's not at all clear to me what you mean by "the database" here. GitHub, for instance, store both the repository—which consists of not one but two primary databases—and their own third database associated with the repository. The third database holds things like issues and code reviews. In any case, commits made elsewhere generally have no effect on any of these databases until you (or whoever has access to them) invoke some specific action. GitHub in particular require git push and/or a GitHub-side "pull request" operation to make commits directly accessible within a repository stored on GitHub.

("Directly accessible" here includes the notion of being easy to find. Due to the way GitHub store commits, it's sometimes possible, if you know the commit hash ID, to access a commit even though it's nominally not yet "in" the repository.)

How does git push send files to the VCS?

Technically, it doesn't. It sends objects. The details here get very complicated, but at the top level, we can view this as an exchange of information: the sending Git provides, to the receiving Git, a particular commit hash ID. The receiving Git replies with one of two options: send me that commit or I already have that commit. Send me that commit means, of course, that the receiver does not have the commit. That implies that any files that appear only in that commit must be sent. Files that are in that commit and other commits might not need to be sent. If the commit must be sent, the sender must offer the commit's parent(s); the receiver replies to each of those offers with yes, send it or no, I have it as before. Further yes, send that commit replies invoke yet more offers, until the sender has discovered every commit that must be sent, and—by implication from the "no thanks, already have that one" replies—can now determine which internal tree and blob objects the receiver already has.

Having determined which objects must be sent and which objects the receiver already has, Git can now prepare a so-called thin pack, in which the to-be-sent objects on the sender are delta-compressed against the known-to-exist objects on the receiver. Any of the "smart" protocols that Git uses make use of this trick. If you are running git push, you will see that your Git prints messages about counting and compressing objects. If you are running git fetch—in which your Git obtains commits and other objects from the other repository—you'll see that your Git first receives the objects, then has to count and check and fix up the incoming objects (Git won't store a "thin pack", so the pack must be "fixed" first to be properly thick).

(You might also want to take a look at what is currently chapter 4 of my prototype book here, to get more information, and of course the Pro Git book has a lot to say as well.)

Upvotes: 2

Related Questions