Re: Newbie Query

[Reece Dunn <msclrhd@googlemail.com>]

2009/1/20 Chris Willard <chris@thewillards.co.uk>:
> 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