git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Newbie Query

From
RDReece Dunn <msclrhd@googlemail.com>
Date
Jan 20, 2009, 20:17 UTC
Message-ID
<3f4fd2640901201217x22262655w115cc2a25e32865e@mail.gmail.com>
In-Reply-To
<20090120191952.GA25322@uts.thewillards.local>
2009/1/20 Chris Willard <chris@thewillards.co.uk>:
Show 11 quoted lines
> 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
Previous: Sverre RabbelierNext: Nicolas Morey-Chaisemartin
Message 4 of 11 in “Newbie Query”
  1. Chris WillardJan 20, 2009
  2. Tomas CarneckyJan 20, 2009
  3. Sverre RabbelierJan 20, 2009
  4. Reece DunnJan 20, 2009
  5. Nicolas Morey-ChaisemartinJan 20, 2009
  6. Boyd Stephen Smith Jr.Jan 20, 2009
  7. Nicolas Morey-ChaisemartinJan 20, 2009
  8. Boyd Stephen Smith Jr.Jan 20, 2009
  9. Jeff KingJan 20, 2009
  10. Johannes SchindelinJan 21, 2009
  11. Chris WillardJan 21, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.