Using git – Part II

Well I can say I’m very happy with git. I actually use it now too to maintain this blog, not the posts them self but the layout, additional plugins etc. While doing this I ran into something odd.
Maybe a little bit of an explanation on how it’s et up right now. I have a main repository folder and a working repository, maybe it’s not the ideal situation but that’s the way it is.
Whenever I make changes I can check them locally as the working folder is also the folder for my local Apache, so I can see changes while I’m working. When satisfied I push the working repository and I update my remote website from the main repository, at least that’s the way I wanted it to work.
The first time I made changes I pushed them out and uploaded the folder to my remote website with FTP. I checked the remote website and the changes I made weren’t there. So I checked my local testsite and sure enough the changes were there. I pulled the main repository and it said everything was up to date, I pushed again and the same reply, everything is up to date. OK, now I’m confused. I checked the changed file in my working folder and the changes were there but when I checked the same file in the main repository folder and the changes weren’t there! What was happening? A git-status in the main repository showed the changes I pushed earlier weren’t committed. Time to search the Internet 🙂

The FAQ on the git website gave me the answer:

Why won’t I see changes in the remote repo after “git push”
The push operation is always about propagating the repository history and updating the refs, and never touches working tree files. Especially, if you push to update the branch that is checked out in a remote repository, you will not see the files in the work tree updated. This is a conscious design decision. The remote repository’s work tree may have local changes, and there is no way for you, who is pushing into the remote repository, to resolve conflicts between the changes you are pushing and the work tree has. However, you can easily make a post-update hook to updating the working copy of the checked out branch. The main problem with consensus of making this a default example hook is that they only notify the person doing the pushing if there was a problem. (see http://lists-archives.org/git/611684-contrib-hooks-add-post-update-hook-for-updating-working-copy.html or the earlier, more easily cut-able  and past-able version http://lists.zerezo.com/git/msg595210.html) A quick rule of thumb is to never push into a repository that has a work tree attached to it, until you know what you are doing. See also the entry (How would I use “git push” to sync out of a firewalled host?) in this FAQ for proper way to work with push with a repository with a work tree.

Ok, that explains it and it makes sense but I didn’t think about it. It just tells me I should RTFM before using software 🙂

Well I can say I’m very happy with git. I actually use it now too to maintain this blog, not the posts them self but the layout, additional plugins etc. While doing this I ran into something odd.
Maybe a little bit of an explanation on how it’s et up right now. I have a main repository folder and a working repository, maybe it’s not the ideal situation but that’s the way it is.
Whenever I make changes I can check them locally as the working folder is also the folder for my local Apache, so I can see changes while I’m working. When satisfied I push the working repository and I update my remote website from the main repository, at least that’s the way I wanted it to work.
The first time I made changes I pushed them out and uploaded the folder to my remote website with FTP. I checked the remote website and the changes I made weren’t there. So I checked my local testsite and sure enough the changes were there. I pulled the main repository and it said everything was up to date, I pushed again and the same reply, everything is up to date. OK, now I’m confused. I checked the changed file in my working folder and the changes were there but when I checked the same file in the main repository folder and the changes weren’t there! What was happening? A git-status in the main repository showed the changes I pushed earlier weren’t committed. Time to search the Internet 🙂

The FAQ on the git website gave me the answer:

Why won’t I see changes in the remote repo after “git push”
The push operation is always about propagating the repository history and updating the refs, and never touches working tree files. Especially, if you push to update the branch that is checked out in a remote repository, you will not see the files in the work tree updated. This is a conscious design decision. The remote repository’s work tree may have local changes, and there is no way for you, who is pushing into the remote repository, to resolve conflicts between the changes you are pushing and the work tree has. However, you can easily make a post-update hook to updating the working copy of the checked out branch. The main problem with consensus of making this a default example hook is that they only notify the person doing the pushing if there was a problem. (see http://lists-archives.org/git/611684-contrib-hooks-add-post-update-hook-for-updating-working-copy.html or the earlier, more easily cut-able  and past-able version http://lists.zerezo.com/git/msg595210.html) A quick rule of thumb is to never push into a repository that has a work tree attached to it, until you know what you are doing. See also the entry (How would I use “git push” to sync out of a firewalled host?) in this FAQ for proper way to work with push with a repository with a work tree.

Ok, that explains it and it makes sense but I didn’t think about it. It just tells me I should RTFM before using software 🙂

This article is filed under the categories Software » git and has the following tags associated with it: , .
  • Hi, same issue for me, and I found a workaround which saved my life, or almost ;-).

    On the B repository, you can commit the pushed changes by typing
    git log,
    Copy the last tag, the one you just comitted on the A repository, you should see it on top. it’s the a71610d95aae9448896b2cf34aed40b5a0f7dfb0 like string
    Then type

    git reset --hard a71610d95aae9448896b2cf34aed40b5a0f7dfb0

    and git return something like

    HEAD is now at a71610d... your commited message

    et voilà!