No announcement yet.

Git Repository only has git files?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Git Repository only has git files?

    Hi I'm relatively new to Git so be gentle

    ok so I have watched many videos now and read plenty and get the idea however there is one thing that has been bugging me. A colleague of mine said that he has a local repos which he handles using Git. He goes to this centrally stored Git repos then clones from this then copies the cloned repos back to the central location. After what I have read so far this seems an odd practice also the centrally stored Git repos that he's cloning from only has Git files, I was expecting it to have the source files and a git folder. To confirm in the folder which has been named project.git/ contains hooks, info, objects, refs. Cloning from this works fine but if I setup a new Git repos it has the source files in there and if I remove the source files leaving just the Git folder it obviously updates the Git folder to tell it there's nothing left.

    Just to add to this, I tried the following. I created a new Git repos, populated as normal then copied just the .git folder as the centrally stored Git repos which I can clone which (which works fine). Is it ok to do it this way? any pitfalls? when I clone from this, edit then commit will the commits only commit to my cloned copy or will they make it back to my centrally stored copy?

    I hope I've explained the scenario properly, any pointers would greatly appreciated.


  • #2
    Server-based Git repos are known as "Bare" (created using the "--bare" option). They ONLY have the Git internal files: there is no facility for a working area.

    When you clone, if your purpose is to make changes, etc. then you must not use the "--bare" option since if you do you'll end up with a repo that is incapable of enabling you to make such changes.

    You probably need to get more information on exactly "how" your colleague is copying them back to the server. If they're not actually doing a push (the normal mechanism to get changes back from a work-clone to an upstream repo), then he's going to have to restructure the repository's guts during the copy. It can be done, but why the heck would you do that???


    • #3
      Hi DougR,

      Thanks for the quick response and valuable information. looking a little further into this I can also confirm that commits made to a cloned copy from bare repos automatically commit back to the centralised bare repos (without the need for push). So I'm checking with the person involved but I'm guessing I can now dispose of the cloned copy as the commits are back in the central bare repo (I've checked first )

      I'm going to go and read up some more on bare repos as I will likely have to create one of these at some point.

      cheers Baldy
      Last edited by DougR; 03-13-2018, 02:53 PM.


      • #4
        WARNING: commits made into the clone'd repository will NOT end up in the bare repository without a "git push". There's no magic here: you choose when to integrate your changes into the upstream repository (and that's done via "git push"). Cheers.


        • #5
          yes, I just worked this out ha ha. as you say the commits are only committing to my cloned copy. A final git push then places this back in the central repo. I think I have this nailed now, have created a few demo bare repos, edited committed, pushed..etc..

          Thanks once again for your help.

          Last edited by DougR; 03-13-2018, 04:29 PM.