On Sat, Mar 06, 2010 at 11:02:20PM -0600, Thomas Anderson wrote: > > How, then, do I update code? ie. I perform my initial clone, make > some changes and commit / push them. Someone else then comes along, > makes some changes and commits them. The next day, I do Remote -> > Fetch from -> origin to update my code to the latest in Git but > c:\git\test\clone\README is exactly the same as it was before. How do > I update the initial clone such that I can edit the updated files? There are a few ways to do that. It depends on what you actually wants. First of all, you can merge 'origin/master' (or whatever its name). If you do not have any local commit then merge will just fast-forward your branch to the same point. However, if you do have changes, then it will create a new merge commit. If you have many such merge commits, it can make the upstream unhappy, because your changes are intervene with merges, so it is more difficult to inspect your actual changes. Another option is to rebase your changes on top of the 'origin/master'. Rebasing your changes on top origin/master is more close to what happens when you do 'cvs update' does, except that in git you rebase committed changes, so if something goes wrong during this process, you can abort and redo it again. So, all your work will not be lost. The advantage of 'rebase' is that you have a clean and linear history. The disadvantage is that you re-write all your commits, so you should not do that on "published" history. Also, re-writing may introduce a problem even if rebased had no conflict. While merge may also produced a non-working result, 'merge' preserves the original history while rebase produces a new one, which is not tested. So, I would not recommend to rebase any long series of patches or anything non-trivial unless it is absolutely necessary. Finally, a typical workflow with Git is to use feature branches. You create a new branch to implement some feature, do all your work on it (without any "update") and then merge it to the upstream (either you merge and push the result or send a pull request to the maintainer). After your changes have been merged, you just delete this branch. For each new work, you start a new branch from the current origin/master. Dmitry -- 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