1

Suppose I do this.

Using github

  1. on local machine: git init testrepo

  2. on github: make a repo test.git pressing buttons in the web interface

  3. on local:

cd testrepo

git remote add origin https://github.com/Someuser/test.git

and then:

touch somefile

git add .

git commit -m 'first'

git push -u origin master

Everything is fine and I have my somefile syncronized to github repo.

Using a remote server

  1. on local machine: git init testrepo

  2. on remote machine:

git init test.git*

  1. on local:

cd testrepo

git remote add origin remotemachine:~/test.git

and then:

touch somefile

git add .

git commit -m 'first'

git push -u origin master

Oh, no!..

Error message.

! [remote rejected] master -> master (branch is currently checked out)

Everything looks the same. Why does github act differently?

Optionally, what is the remedy? Optionally - because you'll see a bunch of proposed solutions in the below question but none of them is accepted answer.

I am aware of this question Git push error '[remote rejected] master -> master (branch is currently checked out)'

However it doesn't answer my question.

*After getting my question answered I have understood that git init test.git is a bad practice going reverse to conventions. Because it creates a folder with a .git folder inside of it. This .git folder IS a repo. And what is INSIDE a newly created folder APART from .git IS A WORKING SPACE.

git init test.git --bare is ok, however, because this command creates a test.git folder (a bare repo) corresponding to what would be inside a .git folder mentioned above.

Andrew Anderson
  • 1,044
  • 3
  • 17
  • 26
  • 1
    The presented facts don't add up. You never create a repo on the server, only an empty directory. If you had created a repository, you must create it with `--bare`. The error message that you presented is shown when pushing into regular, non-bare repositories. Your linked question has the answer; can you explain why you think it doesn't? – knittl Nov 17 '22 at 21:03
  • @knittl yes, I have edited. Thank you. The linked question explains how to ovecrome this issue but my question relates to why we don't experience this issue if we use github to push commits. – Andrew Anderson Nov 20 '22 at 21:31

1 Answers1

1

Everything looks the same.

Only looks. Really the situations are different.

Why does github act differently?

Because at GiHub no branches are checked out. Repositories at GitHub are bare (no working trees).

The bottom line: if a remote repository is intended to be pushed to it should be bare.

See these questions and answers about bare repositories:

What's the -practical- difference between a Bare and non-Bare repository?

What is the difference between "git init" and "git init --bare"?

phd
  • 82,685
  • 13
  • 120
  • 165
  • If a newly created GitHub repo is bare out of the box can you please explain why can we see the files in this repo in the browser? Shouldn't a bare repo store the files somewhere under the hood as blobs? – Andrew Anderson Nov 18 '22 at 13:28
  • 1
    @AndrewAnderson Web interfaces don't necessary show files from the disks/storages. Most web sites these days show their pages from databases. There're many web interfaces that show content of trees and blobs from Git Object Database without extracting them to files. Guthub/Gitlab/Bitbucket are The Three Major Ones. [gitweb](https://git-scm.com/docs/gitweb) and [cgit](https://git.zx2c4.com/cgit/) are the most known small ones. But there're really dozens if not hundreds [such web interfaces](https://stackoverflow.com/a/44246093/7976758). – phd Nov 18 '22 at 13:47
  • 1
    @AndrewAnderson Even locally, for a bare repo, you can run `git ls-tree $treeish` and it will show you the files in the tree. You don't need a working directory for that. And `git cat-file -p` can show the content of any blob or object, so you don't even have to have the files checked out. – knittl Nov 18 '22 at 15:51
  • @phd That makes sense now! I thought what i was seeing as files in the GitHub are actual files and they're not! This misled me into thinking that in the GitHub we do a non bare repo with a working tree. And the fact that we can run some script in GitHub on schedule with GitHub action only added to this my misconception. – Andrew Anderson Nov 18 '22 at 15:56
  • 1
    @AndrewAnderson GitHub Actions run in separate (from the web interface) virtual machines and usually the 1st step of any workflow is to (shallow) clone the triggering repo and checkout the commit — i.e. checkout files from blobs in the Object DB. – phd Nov 18 '22 at 17:18