1

According to https://www.git-tower.com/learn/git/ebook/en/command-line/basics/basic-workflow#start

In Git, the repository is just a simple hidden folder named ".git" in the root directory of your project.

But Git for beginners: The definitive practical guide says

A git repository is simply a directory containing a special .git directory

Does "repository" refer to the hidden .git folder or the directory containing a .git directory?

I know that when you git commit, you are logging changes into your local .git folder. Does this mean when we push to a remote repository like one hosted on GitHub, we are just pushing the contents of the .git folder and nothing else?

csguy
  • 1,354
  • 2
  • 17
  • 37

1 Answers1

3

Does "repository" refer to the hidden .git folder or the directory containing a .git directory?

In strict sense the repository is only .git/ subdirectory. The directory that contains .git/ and all project files is called "working tree", and in strict sense .git/ subdirectory doesn't belong to the working tree.

But people are people, we use relaxed terminology, so we often call the entire working tree + .git/ "repository" or "project" or whatever.

I know that when you git commit, you are logging changes into your local .git folder. Does this mean when we push to a remote repository like one hosted on GitHub, we are just pushing the contents of the .git folder and nothing else?

Short answer: yes.

Longer answer is complex. Yes, git push only pushes objects from Git object database, and pushes references (branches and tags). But there are more things in .git/ that are never pushed or pulled: the config file, hooks and many other files and directories related to the current repository.

phd
  • 82,685
  • 13
  • 120
  • 165
  • so the .git folder stores project files correct? and what is displayed in the github website when you click on a repo is just those files displayed? – csguy Dec 16 '19 at 01:10
  • 1
    And there are also bare repositories which is like the `.git` directory without the working tree: https://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/ – Sly_cardinal Dec 16 '19 at 01:15
  • `.git/` stores object database, references, config file, hooks and a lot of auxiliary and temporary files. Project files are stored in the working tree. Web interfaces (whether it's hosting at Github or self-hosting + CGI script like `gitweb` or `cgit`) show content of the object database. Git hostings like Github or Gitlab doesn't even have files — they store object database in SQL databases. Self-hosted web UI usually also don't have working trees — only `.git/` directories. – phd Dec 16 '19 at 01:21
  • @phd so if we only push the .git folder when we do git push, then how does github display each project file? would that be from the object database that you're talking about? – csguy Dec 16 '19 at 01:34
  • I thought that .git would hold project files because https://stackoverflow.com/questions/8198105/how-does-git-store-files "Git does include for each commit a full copy of all the files, except that, for the content already present in the Git repo, the snapshot will simply point to said content rather than duplicate it. That also means that several files with the same content are stored only once." – csguy Dec 16 '19 at 01:35
  • 1
    @csguy: you will have to define your term "project file". Some development environments (IDEs) store one or more metadata files that they call "project files". So you could mean these files specifically. Other people use the phrase "project files" to mean "files that are part of my project, i.e., my source code and documentation that I'm version-controlling". – torek Dec 16 '19 at 01:43
  • @torek Oh I see, I was referring to project files as in files that are apart of the project – csguy Dec 16 '19 at 01:47
  • 2
    OK. So: each *commit* in Git stores a full snapshot. The exact mechanism isn't important, at this level—you could use Mercurial instead of Git, for instance, which has very different mechanisms and a different underlying storage format for commits. But the idea is: given some commit—whose name, in Git, is really a big ugly hash ID—you can tell Git: *fill my working tree with the contents of that commit.* Git actually does this in two steps, because first it fills in what it calls the *index* or the *staging area*. – torek Dec 16 '19 at 01:50
  • 1
    If you want to know the details of *how* Git fills the index/staging-area and then your working tree, Git actually tells you all of this. Mercurial doesn't: it has no staging area, and does not tell you *how* it extracts the commit to the working tree. You don't need to know the "how" in order to just *use* it, in Mercurial. In Git, you *do* need to know about the index, unfortunately. You don't need to know the remaining details (of how a commit stores everything), but it may help you to understand how the index / staging-area works. That's where your "how does Git store files" Q&A come in. – torek Dec 16 '19 at 01:52