2

I have a quite specific need, and I can’t get it to work, hence I turn to you, Git and Stack Overflow friends.

I have a server my live site runs on. I wish to update the site using Git. To avoid live testing, I wish to set up a testing environment on the same server, accessible through a subdomain, as if the development folder is a branch of master.

As far as I know, you can’t have branches in different folders, which makes sense. Instead, I cloned the live repository into another folder. From my home computer, I push to a feature branch of the development repository, where I merge it with the “remote” master branch and then push the merges to the live server.

Workflow

Unfortunately, when I try to push my development master to live master, git log does mention the new commits, but the files remain the same. This question appears relevant, but no answer solved my problem.

What I do (in chronological order)

  1. ~/www $ git init
  2. ~/www $ git touch file.txt (and fill it)
  3. ~/www $ git add .
  4. ~/www $ git commit -m "Initial commit"
  5. ~/dev $ git clone ~/www .
  6. Make some changes to ~/dev/file.txt
  7. ~/dev $ git add .
  8. ~/dev $ git commit -m "Dev commit"
  9. ~/dev $ git push

When inspecting ~/www/file.txt, nothing has changed :(

A git log command in ~/www (the original repository) does show the commit:

commit 677fed22f18d2a98c9b03fc4256c2ef78bd68e8d
Author: Tim Severien <tim********@gmail.com>
Date:   Sat Feb 14 16:36:38 2015 +0100

    Dev commit

commit 7dd9b40dd29a63ba8ea7d647b4afd575f2376659
Author: Tim Severien <tim********@gmail.com>
Date:   Sat Feb 14 16:35:39 2015 +0100

    Initial commit
  1. Why doesn’t my live repository change?
  2. Do you have better ideas for this kind of workflow?
Community
  • 1
  • 1
Tim S.
  • 13,597
  • 7
  • 46
  • 72
  • 2
    You're likely to scare away a good few potential answerers by addressing them as "gods". Most of us are mere *demigods*, at best `:)` More seriously, I'm afraid your problem is going to be difficult to diagnose without more information. Could you edit it and add the sequence of commands that your typical workflow consists in? – jub0bs Feb 14 '15 at 15:16
  • @Jubobs Thanks for your comment! Changed “gods” to “friends” to make the question more accessible ;) Also, I added a step-by-step description of what I do :) – Tim S. Feb 14 '15 at 15:39
  • `git status` in `~` gives me a fatal error, saying it’s not a repository. If you meant `~/www`, it tells me there are some changes that are yet to be committed, which seems odd. – Tim S. Feb 14 '15 at 15:46
  • @Jubobs Nothing unexpected. Counting objects, writing objects, unpacking projects, all 100% done. Trying another push tells me everything is up-to-date. `git remote -v` tells me `origin /path/to/www (fetch) origin /path/to/www (push)` All seems fine :( – Tim S. Feb 14 '15 at 15:52
  • 1
    Probably relevant: I set `receive.denyCurrentBranch` to `ignore`. – Tim S. Feb 14 '15 at 15:54
  • 2
    Pushing to the checked out branch in a non-bare repository is generally not what you want to do – Andrew C Feb 14 '15 at 15:55
  • @AndrewC Probably not, but I’m having difficulties to find a better way, hence the question “Do you have better ideas for this kind of workflow?” Feel free to suggest ideas :) – Tim S. Feb 14 '15 at 15:58
  • You should be able to find some good articles searching on "git receive hook deploy" – Andrew C Feb 14 '15 at 16:01

2 Answers2

1

It's a bit unusual to push to a non bare repo. Not that it can't work, but, as you're noticing, it can be a bit subtle. Moreover, doing this, you have the full history of your project, on your web server. It's not an issue in itself, but it seems it's wasting space needlessly.

What about adding to your repo a deploy.sh script instead? It could be for instance as simple as

cp -r . ~/www

A first advantage is that it would solve your push issues. An other advantage is that you could make it evolve, as you'll discover other needs. For instance, a second iteration could look like

INITIAL_SHA1=$(git rev-parse HEAD)
SHA1_TO_DEPLOY=$1
DEPLOY_ENVIRONMENT=$2

git checkout $SHA1_TO_DEPLOY
if ! ./runTests.sh; then
  echo Commit $SHA1_TO_DEPLOY is corrupted. Won't deploy it
else
  cp -r . $DEPLOY_ENVIRONMENT
fi
git checkout $INITIAL_SHA1

Of course, this is not a direct answer to your question, however I believe it might answer your needs.

gturri
  • 13,807
  • 9
  • 40
  • 57
0

HEAD is out of sync with the index and the working tree

By setting receive.denyCurrentBranch to ignore in the repository living in ~/www, you're allowing pushes to its checked-out branch (master, here), which brings the HEAD out of sync with the index and the working tree.

This phenomenon is explained in the git-config man page:

receive.denyCurrentBranch

If set to true or "refuse", git-receive-pack will deny a ref update to the currently checked out branch of a non-bare repository. Such a push is potentially dangerous because it brings the HEAD out of sync with the index and working tree. [...] If set to false or "ignore", allow such pushes with no message. [...]

(my emphasis)

Try running

$ git diff
$ git diff --cached
diff --git a/file.txt b/file.txt
index ce01362..e69de29 100644
--- a/file.txt
+++ b/file.txt
@@ -1 +0,0 @@
-hello

in ~/www. Note that git diff outputs nothing, proving that the working tree and the index are in sync, whereas git diff --cached shows a difference between HEAD and the index.

What you're doing wrong

As pointed out by Andrew C in his comment,

Pushing to the checked out branch in a non-bare repository is generally not what you want to do

... for the reason discussed above.

What you should do

You should rethink your workflow and avoid that. The question Push to a non-bare Git repository and its answers should be relevant, here.

Community
  • 1
  • 1
jub0bs
  • 60,866
  • 25
  • 183
  • 186