Issue updating files during a checkout from a remote push

Hi there,

Hoping someone could point me in the right direction here.

The overall issue is that with files that have been pushed into our repo on our server, when we then check out into local working copy the new files appear, but the updated files dont update even though the output suggests it has. The flow I'm doing:

1. The file I'm testing an update to is this:

-rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git- test3.txt

2. On my local box I change file, add it, commit, then push it from my  
local box to our server repo:

StevePoota:public_html steve$ vi steve-git-test3.txt
StevePoota:public_html steve$ git add steve-git-test3.txt
StevePoota:public_html steve$ git commit
Created commit e29b724: testing only
  1 files changed, 1 insertions(+), 0 deletions(-)
StevePoota:public_html steve$ git push ssh://idibu.com/home/beta_idibu/public_html 
  master:master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 272 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://idibu.com/home/beta_idibu/public_html
    a28332a..e29b724  master -> master

3. It all looks good, on my server if i do a 'git log' I can see in  
the latest update:

oneworld:/home/beta_idibu/public_html# git log
commit e29b7246beab458d6a7b53cb245a5596adc8c198
Author: Steve <steve@StevePoota.local>
Date:   Thu Nov 6 17:55:21 2008 +0100

     testing only

4. So I check out:

oneworld:/home/beta_idibu/public_html# git checkout master M .gitignore M steve-git-test.txt M steve-git-test2.txt M steve-git-test3.txt Already on branch "master" oneworld:/home/beta_idibu/public_html#

and its telling me that file has been modified

but checking my file it hasnt changed by date stamp, and looking insie the file my changes arent there :((

-rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git- test3.txt

I'm stumped. I tried 777'ing that file temporarily in case git couldnt write to that file on checkout. What is strange is that when I add new files to the system it works - for example this file I'm testing no was originally added to the server via an external push.

If anyone could give me some help I'd be very grateful.

Kind regards, Steve.

Sorry to keep answering my own questions directly after posting...

I just tried with a 'git commit -f' and the files updated.

Can anyone tell me if this is good practice? I would have thought a normal commit would update from index to head - isnt always forcing it creating potentially bad merges?

Kind regards, Steve.

On Nov 6, 2008, at 6:04 PM, Steve Walker wrote:

www.idibu.co.uk steve@idibu.com

Sales: +44 (0)800 311 2750
Support: +44 (0)870 626 4268
Fax: +44 (0)8701 417 136

Mobile: +34 661 785 387
www.linkedin.com/in/stevejwalker

Hi Steve,

I think you are making the same mistake as I did when I first started using git.

You can't push to "master" from a remote repository because if you do, the index and working files associated with the receiving repository look as if they have been changed because they are out of date WRT the repository.

If you want to push to a repository that has working files associated with it, push to a remote branch in that repository and then merge the contents of the remote branch into the working files. I.e. don't push to "master", push to "remotes/somename/master" and then merge somename/master into the master branch.

That's what I do now to migrate changes from my satellite development machines to my master machine.

Cheers,

Mark

On Thu, Nov 06, 2008 at 06:17:54PM +0100, Steve Walker wrote:

There is no "-f" option to commit. Did you mean "checkout -f"?

If that is the case, then yes, that will "fix" your problem in that it brings the HEAD, index, and working tree into sync. But it is dangerous in that it throws away any local changes you might have had.

If you did really mean "commit" then that is also a bad solution. It creates a new commit on top of the recently pushed work that reverts all of the changes made by the recently pushed work.

-Peff

Steve Walker wrote:

git reset --hard master

Note that it's definitely not a good idea to push into a non-bare repo where you modify the worktree, as the workflow requires that you simply clobber them (or work on a separate branch and then merge with master, but then you'll have to know *why* things happen and how to fix them).

You'd probably be better off pushing to another repository and fetching from that other repo into the non-bare one you're using now.

On Thu, Nov 06, 2008 at 06:04:20PM +0100, Steve Walker wrote:

The short answer is: don't push into the current branch of a non-bare repo.

OK, so this updates the HEAD of the receiving repository. But the index and working tree are untouched.

Right, because the HEAD has been updated.

But you were already _on_ master, so git shouldn't need to touch the index and working tree. But the contents of master have changed out from under you, so it looks like you have modifications.

So generally you don't want to push to the current branch, but there is no safety valve disallowing it (and I will post a patch series in a minute which introduces one). In the past, people have suggested doing a merge with the working tree, but that is not desirable for two reasons:

  1. you are changing the working tree out from under whoever's repo you
     push into

  2. the merge might not be clean, in which case the user needs to
     resolve conflicts. But the user isn't even doing stuff in the
     now-conflicted repository. So the suggested workflow is instead to
     go to that repo and do a 'pull'

So depending on what you want to accomplish, there are a number of alternative workflows:

 - if you just want to publish refs, you can use a bare repo without a
   working tree at all (git --bare init, or git clone --bare).

 - if you just want to throw away working tree changes on a push (e.g.,
   you are pushing to a production server whose working tree is kept up
   to date), you can do that automatically with a post-receive hook. But
   it will never be the default, because we don't want to throw anything
   away unless the user has explicitly told us to do so.

 - if you are working in repos A and B, and you want to get changes from
   B to A, then you would generally go to A and "git pull B". But
   sometimes that is not possible (e.g., you can only make network
   connections one way). In that case, you can push to a "remote" branch
   on A, and then merge from there when you're at A. E.g.,:

     /repo/B$ git push /repo/A master:refs/remotes/B/master
     /repo/B$ cd /repo/A
     /repo/A$ git merge B/master

-Peff