GIT push - remote: fatal: This operation must be run in a work tree

Question

I'm new to GIT. I create repository with commands:

cd /home/user_name
mkdir repo && cd repo
mkdir site.git && cd site.git
git init --bare

then in the hooks directory, I create the post-receive file and add there:

#!/bin/sh
git --work-tree=/home/user_name/dev.ireserve.com --git-dir=/home/user_name/repo/site.git checkout -f

after that, I add permissions: chmod +x post-receive

at my local machine in the laravel project directory I run:

git init

then I run:

git remote add live ssh://root@example.com/home/user_name/repo/site.git

after that usually:

git add .
git commit -m "my message"

and at the end :

git push live master

but I got a message:

remote: fatal: This operation must be run in a work tree

Why I got this error? What is a problem?

Answer 1

From the comments, you have 1 directory on both sides, you need to start creating versions so you can use the real power of GIT.

You need to create branches(versions) if you are willing to use GIT add.

check this answer

for adding branches, check this tutorial.

and this is the tutorial from the start.

This is the best tutorial, IMHO; for GIT.

It will save a lot of effort and time.

Happy coding!

Answer 2

TL;DR: I think a mkdir step is missing from your Laravel setup instructions.

---

This command:

git init --bare

is meant for making server repositories in which no one will ever do any work.

Now, that might seem an odd thing to do: why create a repository where no one can work on the repository? And it is an odd thing to do, but it exists for a reason.

Bare vs non-bare repository

If you make a repository where you can work:

git init

then you can work in it, but—to oversimplify a bit—no one else should ever just send you their work unannounced. But people also need to share work, and one common usage pattern is that everyone agrees that some work-sharing repository, over on some central server such as the corporate "master source repository" machine, should be the place to which everyone sends work.

At the same time, though, you don't want to have to have someone who spends all day taking people's work into that central repository. You want to let people send their work as soon as it's ready, so that everyone else can go to the central repository to see (or even obtain and use) their work right away. So you need a place that peole can send their work, unannounced, right now.

That's a --bare repository. Since no one works in it, you won't overwrite their in-progress work by sending your completed work.

This is really about the difference between a commit and a work-tree

Making a new commit makes a permanent and incorruptible¹ snapshot of your work. But it has to get this from somewhere. The minimum "somewhere" is found in other version control systems as the work-tree: the place you do your work. Git inserts an extra wrinkle here, and forces you to know about it: it adds the index, also called the staging area or sometimes the cache (three names for one thing—it's a very important entity in Git!). The index and work-tree come as a pair, though: they're where you can write things. Commits, once made, are entirely unchangeable, which is what makes them incorruptible. So you need a place to work, where you can both read and write files.

A bare repository holds commits—the read only snapshots—but has no work-tree.² That's pretty much all there is to it: with no work-tree, there is no place to work. That's what makes it suitable for pushing-to, but without a place to work, you can't do any work in it. You'll need a non-bare repository as well.

---

¹Commits are really only mostly permanent: they last as long as there are names by which one can find them. I'll leave this detail for other tutorials. They are entirely incorruptible though, because the true name of a commit is its hash ID. The hash ID, while quite unpredictable in advance, is a cryptographic checksum of the contents of the commit. If something goes wrong and a commit becomes corrupted, Git will notice, because the contents won't fit the true name hash ID any more.

²For somewhat silly implementation reasons, a bare repository still has an index. It just has no work-tree. They're paired—the index indexes (hence the name) the work-tree—but a bare repository typically still has a completely-empty index it carries around.

---

Some servers fake up a work-tree for a bare repository

You can combine the bare repository (with no work-tree) with Git's hooks mechanism to create a sort of fake work-tree. This is how your Laravel setup is intended to work, for instance. When your bare server receives a git push, the server runs the hook, and the hook runs git --work-tree=<path> checkout -f to set up a temporary work-tree in <path>. This temporary work-tree is the work-tree for the duration of the one git checkout command. (The index now indexes that temporary work-tree.) Then the git checkout finishes and the bare repository continues to have no work-tree. You still can't work in it.

Note that this last git --work-tree=<path> checkout -f won't create a directory <path>. This directory must already exist. It should initially be empty; after the first git checkout -f, it will contain what git checkout wrote; and on each later git checkout -f, Git will assume (via the index) that it contains whatever the last git checkout -f wrote, and update it in place based on this information.

Hence your original Laravel setup should have had a mkdir home/user_name/dev.ireserve.com in it.