Announcement

Collapse
No announcement yet.

http clones empty repository

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • http clones empty repository

    Hello, I have continued with my apache based http git repo and sort of worked.
    I got this stupid error about some sort of gtk warning which got rid of by issuing "unset SSH_ASKPASS" command.

    Now, I setup valid and fully functioning git repo however when using http protocol to checkout, I got following:

    [root@localhost dev-learn]# git clone http://admin@<IP_ADDRESS>:<PORT>/dev-learn/.git
    Initialized empty Git repository in /git.co/dev-learn/dev-learn/.git/
    Password:
    warning: You appear to have cloned an empty repository.


    Something is wrong because there are already master branch and even typing "git branch" outputs nothing not even master branch:

    [root@localhost dev-learn]# git branch
    [root@localhost dev-learn]#


    I can checkout just fine using ssh protocol the same repository:

    [root@localhost dev-learn]# git clone ssh://root@<IP_ADDRESS>/var/www/gitrepos/dev-learn
    Initialized empty Git repository in /git.co/dev-learn/dev-learn/.git/
    remote: Counting objects: 7, done.
    remote: Compressing objects: 100% (4/4), done.
    remote: Total 7 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (7/7), done.


    and can see the files and folders are there, but same files and folders as well as branches are not checked using http protocol from same repo. What gives?

    [root@localhost dev-learn]# git remote -v
    origin ssh://root@<IP_ADDRESS>/var/www/gitrepos/dev-learn (fetch)
    origin ssh://root@<IP_ADDRESS>/var/www/gitrepos/dev-learn (push)
    [root@localhost dev-learn]# ls






  • #2
    My guess would be that the repository on your server is not "bare". There's some ambiguity in your post but if you can see files and folders in the repository on the server then it is definitely not "bare". Server repositories are supposed to be "bare" - there will be no working area in them. One apparent confirmation is the pathname: "bare" repositories are customarily named "<repoName>.git" and in their top-level directory you will find the "config" file. Normal Git repositories that are meant to be worked in are non-bare and have a ".git" directory in their top level directory (in which you'll find the "config" file).

    While "ssh" can be used to clone non-bare repositories, the http/s protocal must work on bare repositories.

    Comment


    • #3
      yes i figured that out, by ls -la and there was .git directory. I made it non bare and it worked. Then anbrother unrelated issue surfaced which after that, git pull-ing was not bringing the latest change through http protocol which I sort of remediated with git update-server-info. I diff-d the folder structures both before and after AND fond .git/info/refs has been updated with latest commit hash.

      Comment


      • #4
        Conclusion is for some reason, cloning repo through http appears to clone bare repository instead of normal.
        The fact that git update-server-info had to issued so that remotely http cloned copy can get latest one seems cumbersome. AFAIK, when I worked mostly with ssh protocol, these were never issue to me.

        Comment


        • #5
          I decided to put in "git update-server-info" in hooks/post-receive and ran one more commit. However looks like the info/refs are not being updated:
          Here the commit of test4.py has 8f0f29fbd0995c3a2eae735e3f1080274b039090 hash however info/refs still has e5c98c93284fe2be29e7e4610aa7382d00210ed9.

          According to git post-receive is server side hooks that should be called after each time "entire process is completed" however apparently is not working in this case.

          https://git-scm.com/book/en/v2/Custo...-Git-Git-Hooks

          commit 8f0f29fbd0995c3a2eae735e3f1080274b039090
          Author: Guyen Gn 10.0.0.160 <guyen000@gmail.com>
          Date: Mon Nov 5 13:00:04 2018 -0800

          test4.py: added

          commit e5c98c93284fe2be29e7e4610aa7382d00210ed9
          Author: Guyen Gn 10.0.0.160 <guyen000@gmail.com>
          Date: Mon Nov 5 12:57:56 2018 -0800

          [root@httpd-server hooks]# cat ../hooks/post-receive
          #!/bin/sh
          #
          # An example hook script for the "post-receive" event.
          #
          # The "post-receive" script is run after receive-pack has accepted a pack
          # and the repository has been updated. It is passed arguments in through
          # stdin in the form
          # <oldrev> <newrev> <refname>
          # For example:
          # aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
          #
          # see contrib/hooks/ for a sample, or uncomment the next line and
          # rename the file to "post-receive".

          #. /usr/share/git-core/contrib/hooks/post-receive-email

          echo "Issuing git update-server-info"
          git update-server-info


          Only after manually did and info/refs is updated:

          [root@httpd-server hooks]# git update-server-info
          [root@httpd-server hooks]# cat ../info/refs
          f2ab23040b8e5500add98bfe4727a91000c4e4c9 refs/heads/dev-1
          8f0f29fbd0995c3a2eae735e3f1080274b039090 refs/heads/master
          [root@httpd-server hooks]#



          Comment


          • #6
            Please do "ls -l hooks/post-receive" to see what permissions are on the hook script. The hook script must be executable. To make it so, you would "chmod a+rx hooks/post-receive".

            Comment


            • #7
              Originally posted by DougR View Post
              Please do "ls -l hooks/post-receive" to see what permissions are on the hook script. The hook script must be executable. To make it so, you would "chmod a+rx hooks/post-receive".
              yes it looks like a permission issue and now it appears to have worked. thx.

              Comment


              • #8
                since my http setup is exploratory project with focus on learning not only for just http server working,
                unset SSH_ASKPASS has gotten rid of error message and blocking from proceeding further.
                Googling shows it is weird stuff related to open-ssh: https://man.openbsd.org/ssh-askpass.1#DESCRIPTION
                Anyone has simpler explanation?

                Comment


                • #9
                  The above post appears to be a new topic (SSH vs. HTTP). If so, please start a new topic. Otherwise, please provide more details as to how this is related to the current topic?

                  Comment


                  • #10
                    with apache git server setup, then you checked out using http protocol, on red hat, you immediately see some sort of GTK related error message:
                    Gtk-WARNING **: cannot open display: That was circumvented by issuing unset SSH_ASKPASS.
                    It is a sad because error is mystified.

                    Comment


                    • #11
                      Which Git client are you using? Which version?

                      Comment


                      • #12
                        Originally posted by DougR View Post
                        Which Git client are you using? Which version?
                        Dont remember the version it could be pretty old that comes OOB with CENTOS6.5

                        Comment


                        • #13
                          Please upgrade to something modern (e.g. 2.18 or later). Then try again.

                          FYI, there are places you can get already compiled/tested binaries for Git.
                          I work for WANdisco, Inc. We provide them free to anyone, we're not the only ones.
                          See here: https://wandisco.com/resource-library

                          Comment

                          Working...
                          X