0

I set up a repository (git init) on an existing unversioned sourcetree in production (don't tell me). After the initial import commit I cloned the repo on my dev machine and started editing.

After the first commit/push everything seemed normal on my local copy but then on the prod server git pull always said "Already up-to-date." and the changes were shown as local modification "negated".

To clarify what I mean with negated: suppose that beside editing, I've added a file (myfile) on my local copy and comitted/pushed it. What I'll see on the server will be:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#       deleted: myfile

along with a series of:

#       modified: other_file

that reflect the files I just committed but with my changes "reverted". History in git log seems linear and consistent.

This is the content of .git/config on the server:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = user@host:repo
[branch "master"]
    remote = origin
    merge = refs/heads/master

On my local copy it's the same plus:

ignorecase = true
precomposeunicode = false

in the [core] section.

  • dev machine git version 1.8.1.1
  • prod machine git version 1.5.6.5 (I know, it's old, but I can't update it right now)

Could be something relative to tracking? I'm quite baffled right now and to make it worse, seems like I'm the only one on the whole internet experiencing something similar.

michaelb958--GoFundMonica
  • 4,617
  • 7
  • 31
  • 35
karl
  • 3
  • 2
  • To obtain the changes on the server in practice, I need to reset to HEAD every modified file and checkout it from the last commit (commit history is correct and consistent). Another thing I noticed (but I can't say if it's normal or not) it's that when I pull from the production server git asks me the ssh user password as if going to fetch the changes remotely. aren't they already on the server? – karl May 24 '13 at 09:40

1 Answers1

1

You are pushing to a non-bare repo. You should not do that. Read up on what remote tracking branches are, and what git push and git fetch do. You are changing which commit that the checkout out branch on the server is pointing to without updating the working copy (that is the effect of pushing to a non-bare repo).

So now git status on the server notices that the working directory is different to HEAD. It assumes the only logical thing: you must have done changes to the working dir. That’s what git status is reporting. There are two solutions to this problem:

  • Do not push to the production server repo. My personal recommendation. Set up a bare repo somewhere else and push there. Add it as a remote to the production server repo. When you want to deploy, ssh into the server and pull. This also separates revision control from deployment.

  • Set up a hook on the server that does a checkout on push. You can find more infos on that approach in the GitFAQ

Chronial
  • 66,706
  • 14
  • 93
  • 99