2009/1/20 Chris Willard <chris@xxxxxxxxxxxxxxxxx>: > Hello All, > > I then modified the files, added them, commited the changes and then > used git push to put them on the PC - still no problems. > > Both systems show the commits but the PC does not have the latest > version of the files. Git status on the PC shows the file as changed > but commiting give an error when pushing from the laptop. > > I assume that I need to run a command on the PC to get both systems > the same. Is it a reset or something else? So IIUC running 'git log' on the machine you pushed the changes to, you can see the checkin you made on the machine you made the change on? You need to run 'git checkout' on the machine you pushed to, to tell git that you want these files. This is a safety feature, since someone may be working on the files on that machine locally, and so doesn't want them being overwritten by your push. You may find the documentation (http://git-scm.com/documentation) useful, especially http://www.kernel.org/pub/software/scm/git/docs/everyday.html which has your scenario under "Push into another repository. ". If you want someone to take some changes you made, it is recommended to let them know so that they can run 'git pull' or 'git fetch' to get your changes (performing a merge or rebase as desired). This means that they control when they get the updates and what they want to do with them. If you are committing the files to a shared public repository (e.g. a central repository, or build server repository), a pussible approach is to create that as a "bare" repository (one with just the contents of the .git folder - i.e. it does not have any files checked out). You can do this by running: git clone --bare source/git/path/project project.git you can then clone from this: git clone my/shared/project.git and push any changes to it as normal. The build server can then do a 'git pull' to get the new changes from that repository. You can keep it setup like you currently have (assuming that where you are pushing to is a shared repository), and do: git checkout HEAD before you run a build (assuming this is the repository that you are using for your builds). The advantage of a bare repository is that it will take up less space, and using a different (cloned) repository for performing builds keeps the main repository clean. One of the great things about git is that you can customise it to fit different workflows. HTH, - Reece -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
