<h2>update</h2>

<u>Updating</u> a repository is the process of applying to it changes
made by external entities.  Contrast this with [./cmd_commit.wiki |
commit]ing a locally made change; updating is a bit like "committing"
external changes to the local repo.

Update <em>merges</em> changes from the repository into your checkout.
That means that it won't have any effect unless there <i>are</i>
changes in the repository.  The only way the checkout can affect
the repo (this is the local repo we're talking about) is if you
do a [./cmd_commit.wiki | <code>ci</code>].  So, <code>update</code>
only really makes sense if you have
[./cmd_pull.wiki | <code>pull</code>]ed changes from the master repository
into the local repository.

<annotation>
  Note :
  really really need a quick overview of the pull-update-edit-commit-push
  workflow, and the shortcuts for that, and re-emphasize the role of autosync
  in changing the basic nature of the workflow
</annotation>

Local intranet <code>[./cmd_commit.wiki | commit]</code>s
(by someone else)
or Net <code>[./cmd_pull.wiki | pull]</code>s from a server
will usually require a <code>fossil&nbsp;update</code> afterward,
because they are likely not to be done in
[./cmd_settings.wiki#autosync | autosync]
mode.

Local commits are likely to be made with
[./cmd_settings.wiki#autosync | automatic syncing]
set to "on", however, so if you don't use <b>fossil</b> for Net-wide
projects you may never have to use <code>update</code>.

See also: [./cmd_pull.wiki | fossil pull],
[./cmd_commit.wiki | fossil commit],
[./cmd_settings.wiki#autosync | fossil setting] (autosync),
[./branching.wiki | <i>branching, merging, forking and tagging</i>],
[./reference.wiki | Reference]
