hgbook
diff en/tour-basic.tex @ 95:47ea206351d5
Split tour into two sections.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Fri Oct 13 14:00:06 2006 -0700 (2006-10-13) |
parents | en/tour.tex@0b97b0bdc830 |
children | 7d7ddc3a57af |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/en/tour-basic.tex Fri Oct 13 14:00:06 2006 -0700 1.3 @@ -0,0 +1,519 @@ 1.4 +\chapter{A tour of Mercurial: the basics} 1.5 +\label{chap:tour-basic} 1.6 + 1.7 +\section{Installing Mercurial on your system} 1.8 +\label{sec:tour:install} 1.9 + 1.10 +Prebuilt binary packages of Mercurial are available for every popular 1.11 +operating system. These make it easy to start using Mercurial on your 1.12 +computer immediately. 1.13 + 1.14 +\subsection{Linux} 1.15 + 1.16 +Because each Linux distribution has its own packaging tools, policies, 1.17 +and rate of development, it's difficult to give a comprehensive set of 1.18 +instructions on how to install Mercurial binaries. The version of 1.19 +Mercurial that you will end up with can vary depending on how active 1.20 +the person is who maintains the package for your distribution. 1.21 + 1.22 +To keep things simple, I will focus on installing Mercurial from the 1.23 +command line under the most popular Linux distributions. Most of 1.24 +these distributions provide graphical package managers that will let 1.25 +you install Mercurial with a single click; the package name to look 1.26 +for is \texttt{mercurial}. 1.27 + 1.28 +\begin{itemize} 1.29 +\item[Debian] 1.30 + \begin{codesample4} 1.31 + apt-get install mercurial 1.32 + \end{codesample4} 1.33 + 1.34 +\item[Fedora Core] 1.35 + \begin{codesample4} 1.36 + yum install mercurial 1.37 + \end{codesample4} 1.38 + 1.39 +\item[Gentoo] 1.40 + \begin{codesample4} 1.41 + emerge mercurial 1.42 + \end{codesample4} 1.43 + 1.44 +\item[OpenSUSE] 1.45 + \begin{codesample4} 1.46 + yum install mercurial 1.47 + \end{codesample4} 1.48 + 1.49 +\item[Ubuntu] Ubuntu's Mercurial package is particularly old, and you 1.50 + should not use it. If you know how, you can rebuild and install the 1.51 + Debian package. It's probably easier to build Mercurial from source 1.52 + and simply run that; see section~\ref{sec:srcinstall:unixlike} for 1.53 + details. 1.54 +\end{itemize} 1.55 + 1.56 +\subsection{Mac OS X} 1.57 + 1.58 +Lee Cantey publishes an installer of Mercurial for Mac OS~X at 1.59 +\url{http://mercurial.berkwood.com}. This package works on both 1.60 +Intel-~and Power-based Macs. Before you can use it, you must install 1.61 +a compatible version of Universal MacPython~\cite{web:macpython}. This 1.62 +is easy to do; simply follow the instructions on Lee's site. 1.63 + 1.64 +\subsection{Solaris} 1.65 + 1.66 +XXX. 1.67 + 1.68 +\subsection{Windows} 1.69 + 1.70 +Lee Cantey publishes an installer of Mercurial for Windows at 1.71 +\url{http://mercurial.berkwood.com}. This package has no external 1.72 +dependencies; it ``just works''. 1.73 + 1.74 +\begin{note} 1.75 + The Windows version of Mercurial does not automatically convert line 1.76 + endings between Windows and Unix styles. If you want to share work 1.77 + with Unix users, you must do a little additional configuration 1.78 + work. XXX Flesh this out. 1.79 +\end{note} 1.80 + 1.81 +\section{Getting started} 1.82 + 1.83 +To begin, we'll use the \hgcmd{version} command to find out whether 1.84 +Mercurial is actually installed properly. The actual version 1.85 +information that it prints isn't so important; it's whether it prints 1.86 +anything at all that we care about. 1.87 +\interaction{tour.version} 1.88 + 1.89 +\subsection{Built-in help} 1.90 + 1.91 +Mercurial provides a built-in help system. This invaluable for those 1.92 +times when you find yourself stuck trying to remember how to run a 1.93 +command. If you are completely stuck, simply run \hgcmd{help}; it 1.94 +will print a brief list of commands, along with a description of what 1.95 +each does. If you ask for help on a specific command (as below), it 1.96 +prints more detailed information. 1.97 +\interaction{tour.help} 1.98 +For a more impressive level of detail (which you won't usually need) 1.99 +run \hgcmdargs{help}{\hggopt{-v}}. The \hggopt{-v} option is short 1.100 +for \hggopt{--verbose}, and tells Mercurial to print more information 1.101 +than it usually would. 1.102 + 1.103 +\section{Working with a repository} 1.104 + 1.105 +In Mercurial, everything happens inside a \emph{repository}. The 1.106 +repository for a project contains all of the files that ``belong to'' 1.107 +that project, along with a historical record of the project's files. 1.108 + 1.109 +There's nothing particularly magical about a repository; it is simply 1.110 +a directory tree in your filesystem that Mercurial treats as special. 1.111 +You can rename delete a repository any time you like, using either the 1.112 +command line or your file browser. 1.113 + 1.114 +\subsection{Making a local copy of a repository} 1.115 + 1.116 +\emph{Copying} a repository is just a little bit special. While you 1.117 +could use a normal file copying command to make a copy of a 1.118 +repository, it's best to use a built-in command that Mercurial 1.119 +provides. This command is called \hgcmd{clone}, because it creates an 1.120 +identical copy of an existing repository. 1.121 +\interaction{tour.clone} 1.122 +If our clone succeeded, we should now have a local directory called 1.123 +\dirname{hello}. This directory will contain some files. 1.124 +\interaction{tour.ls} 1.125 +These files have the same contents and history in our repository as 1.126 +they do in the repository we cloned. 1.127 + 1.128 +Every Mercurial repository is complete, self-contained, and 1.129 +independent. It contains its own private copy of a project's files 1.130 +and history. A cloned repository remembers the location of the 1.131 +repository it was cloned from, but it does not communicate with that 1.132 +repository, or any other, unless you tell it to. 1.133 + 1.134 +What this means for now is that we're free to experiment with our 1.135 +repository, safe in the knowledge that it's a private ``sandbox'' that 1.136 +won't affect anyone else. 1.137 + 1.138 +\subsection{What's in a repository?} 1.139 + 1.140 +When we take a more detailed look inside a repository, we can see that 1.141 +it contains a directory named \dirname{.hg}. This is where Mercurial 1.142 +keeps all of its metadata for the repository. 1.143 +\interaction{tour.ls-a} 1.144 + 1.145 +The contents of the \dirname{.hg} directory and its subdirectories are 1.146 +private to Mercurial. Every other file and directory in the 1.147 +repository is yours to do with as you please. 1.148 + 1.149 +To introduce a little terminology, the \dirname{.hg} directory is the 1.150 +``real'' repository, and all of the files and directories that coexist 1.151 +with it are said to live in the \emph{working directory}. An easy way 1.152 +to remember the distinction is that the \emph{repository} contains the 1.153 +\emph{history} of your project, while the \emph{working directory} 1.154 +contains a \emph{snapshot} of your project at a particular point in 1.155 +history. 1.156 + 1.157 +\section{A tour through history} 1.158 + 1.159 +One of the first things we might want to do with a new, unfamiliar 1.160 +repository is understand its history. The \hgcmd{log} command gives 1.161 +us a view of history. 1.162 +\interaction{tour.log} 1.163 +By default, this command prints a brief paragraph of output for each 1.164 +change to the project that was recorded. In Mercurial terminology, we 1.165 +call each of these recorded events a \emph{changeset}, because it can 1.166 +contain a record of changes to several files. 1.167 + 1.168 +The fields in a record of output from \hgcmd{log} are as follows. 1.169 +\begin{itemize} 1.170 +\item[\texttt{changeset}] This field has the format of a number, 1.171 + followed by a colon, followed by a hexadecimal string. These are 1.172 + \emph{identifiers} for the changeset. There are two identifiers 1.173 + because the number is shorter and easier to type than the hex 1.174 + string. 1.175 +\item[\texttt{user}] The identity of the person who created the 1.176 + changeset. This is a free-form field, but it most often contains a 1.177 + person's name and email address. 1.178 +\item[\texttt{date}] The date and time on which the changeset was 1.179 + created, and the timezone in which it was created. (Thef date and 1.180 + time are local to that timezone; they display what time and date it 1.181 + was for the person who created the changeset.) 1.182 +\item[\texttt{summary}] The first line of the text message that the 1.183 + creator of the changeset entered to describe the changeset. 1.184 +\end{itemize} 1.185 +The default output printed by \hgcmd{log} is purely a summary; it is 1.186 +missing a lot of detail. 1.187 + 1.188 +\subsection{Changesets, revisions, and identification} 1.189 + 1.190 +English being a notoriously sloppy language, we have a variety of 1.191 +terms that have the same meaning. If you are talking about Mercurial 1.192 +history with other people, you will find that the word ``changeset'' 1.193 +is often compressed to ``change'' or ``cset'', and sometimes a 1.194 +changeset is referred to as a ``revision'' or a ``rev''. 1.195 + 1.196 +While it doesn't matter what \emph{word} you use to refer to the 1.197 +concept of ``a~changeset'', the \emph{identifier} that you use to 1.198 +refer to ``a~\emph{specific} changeset'' is of great importance. 1.199 +Recall that the \texttt{changeset} field in the output from 1.200 +\hgcmd{log} identifies a changeset using both a number and a 1.201 +hexadecimal string. The number is \emph{only valid in that 1.202 + repository}, while the hex string is the \emph{permanent, unchanging 1.203 + identifier} that will always identify that changeset in every copy 1.204 +of the repository. 1.205 + 1.206 +This distinction is important. If you send someone an email talking 1.207 +about ``revision~33'', there's a high likelihood that their 1.208 +revision~33 will \emph{not be the same} as yours. The reason for this 1.209 +is that a revision number depends on the order in which changes 1.210 +arrived in a repository, and there is no guarantee that the same 1.211 +changes will happen in the same order in different repositories. 1.212 +Three changes $a,b,c$ can easily appear in one repository as $0,1,2$, 1.213 +while in another as $1,0,2$. 1.214 + 1.215 +Mercurial uses revision numbers purely as a convenient shorthand. If 1.216 +you need to discuss a changeset with someone, or make a record of a 1.217 +changeset for some other reason (for example, in a bug report), use 1.218 +the hexadecimal identifier. 1.219 + 1.220 +\subsection{Viewing specific revisions} 1.221 + 1.222 +To narrow the output of \hgcmd{log} down to a single revision, use the 1.223 +\hgopt{log}{-r} (or \hgopt{log}{--rev}) option. You can use either a 1.224 +revision number or a long-form changeset identifier, and you can 1.225 +provide as many revisions as you want. \interaction{tour.log-r} 1.226 + 1.227 +If you want to see the history of several revisions without having to 1.228 +list each one, you can use \emph{range notation}; this lets you 1.229 +express the idea ``I want all revisions between $a$ and $b$, 1.230 +inclusive''. 1.231 +\interaction{tour.log.range} 1.232 +Mercurial also honours the order in which you specify revisions, so 1.233 +\hgcmdargs{log}{-r 2:4} prints $2,3,4$ while \hgcmdargs{log}{-r 4:2} 1.234 +prints $4,3,2$. 1.235 + 1.236 +\subsection{More detailed information} 1.237 + 1.238 +While the summary information printed by \hgcmd{log} is useful if you 1.239 +already know what you're looking for, you may need to see a complete 1.240 +description of the change, or a list of the files changed, if you're 1.241 +trying to decide whether a changeset is the one you're looking for. 1.242 +The \hgcmd{log} command's \hggopt{-v} (or \hggopt{--verbose}) 1.243 +option gives you this extra detail. 1.244 +\interaction{tour.log-v} 1.245 + 1.246 +If you want to see both the description and content of a change, add 1.247 +the \hgopt{log}{-p} (or \hgopt{log}{--patch}) option. This displays 1.248 +the content of a change as a \emph{unified diff} (if you've never seen 1.249 +a unified diff before, see section~\ref{sec:mq:patch} for an overview). 1.250 +\interaction{tour.log-vp} 1.251 + 1.252 +\section{All about command options} 1.253 + 1.254 +Let's take a brief break from exploring Mercurial commands to discuss 1.255 +a pattern in the way that they work; you may find this useful to keep 1.256 +in mind as we continiue our tour. 1.257 + 1.258 +Mercurial has a consistent and straightforward approach to dealing 1.259 +with the options that you can pass to commands. It follows the 1.260 +conventions for options that are common to modern Linux and Unix 1.261 +systems. 1.262 +\begin{itemize} 1.263 +\item Every option has a long name. For example, as we've already 1.264 + seen, the \hgcmd{log} command accepts a \hgopt{log}{--rev} option. 1.265 +\item Most options have short names, too. Instead of 1.266 + \hgopt{log}{--rev}, we can use \hgopt{log}{-r}. (The reason that 1.267 + some options don't have short names is that the options in question 1.268 + are rarely used.) 1.269 +\item Long options start with two dashes (e.g.~\hgopt{log}{--rev}), 1.270 + while short options start with one (e.g.~\hgopt{log}{-r}). 1.271 +\item Option naming and usage is consistent across commands. For 1.272 + example, every command that lets you specify a changeset~ID or 1.273 + revision number accepts both \hgopt{log}{-r} and \hgopt{log}{--rev} 1.274 + arguments. 1.275 +\end{itemize} 1.276 +In the examples throughout this book, I use short options instead of 1.277 +long. This just reflects my own preference, so don't read anything 1.278 +significant into it. 1.279 + 1.280 +Most commands that print output of some kind will print more output 1.281 +when passed a \hggopt{-v} (or \hggopt{--verbose}) option, and less 1.282 +when passed \hggopt{-q} (or \hggopt{--quiet}). 1.283 + 1.284 +\section{Making and reviewing changes} 1.285 + 1.286 +Now that we have a grasp of viewing history in Mercurial, let's take a 1.287 +look at making some changes and examining them. 1.288 + 1.289 +The first thing we'll do is isolate our experiment in a repository of 1.290 +its own. We use the \hgcmd{clone} command, but we don't need to 1.291 +clone a copy of the remote repository. Since we already have a copy 1.292 +of it locally, we can just clone that instead. This is much faster 1.293 +than cloning over the network, and cloning a local repository uses 1.294 +less disk space in most cases, too. 1.295 +\interaction{tour.reclone} 1.296 +As an aside, it's often good practice to keep a ``pristine'' copy of a 1.297 +remote repository around, which you can then make temporary clones of 1.298 +to create sandboxes for each task you want to work on. This lets you 1.299 +work on multiple tasks in parallel, each isolated from the others 1.300 +until it's complete and you're ready to integrate it back. Because 1.301 +local clones are so cheap, there's almost no overhead to cloning and 1.302 +destroying repositories whenever you want. 1.303 + 1.304 +In our \dirname{my-hello} repository, we have a file 1.305 +\filename{hello.c} that contains the classic ``hello, world'' program. 1.306 +Let's use the ancient and venerable \command{sed} command to edit this 1.307 +file so that it prints a second line of output. (I'm only using 1.308 +\command{sed} to do this because it's easy to write a scripted example 1.309 +this way. Since you're not under the same constraint, you probably 1.310 +won't want to use \command{sed}; simply use your preferred text editor to 1.311 +do the same thing.) 1.312 +\interaction{tour.sed} 1.313 + 1.314 +Mercurial's \hgcmd{status} command will tell us what Mercurial knows 1.315 +about the files in the repository. 1.316 +\interaction{tour.status} 1.317 +The \hgcmd{status} command prints no output for some files, but a line 1.318 +starting with ``\texttt{M}'' for \filename{hello.c}. Unless you tell 1.319 +it to, \hgcmd{status} will not print any output for files that have 1.320 +not been modified. 1.321 + 1.322 +The ``\texttt{M}'' indicates that Mercurial has noticed that we 1.323 +modified \filename{hello.c}. Notice that we didn't need to 1.324 +\emph{inform} Mercurial that we were going to modify the file before 1.325 +we started, or that we had modified the file after we were done; it 1.326 +was able to figure this out itself. 1.327 + 1.328 +It's a little bit helpful to know that we've modified 1.329 +\filename{hello.c}, but we might prefer to know exactly \emph{what} 1.330 +changes we've made to it. To do this, we use the \hgcmd{diff} 1.331 +command. 1.332 +\interaction{tour.diff} 1.333 + 1.334 +\section{Recording changes in a new changeset} 1.335 + 1.336 +We can modify files, build and test our changes, and use 1.337 +\hgcmd{status} and \hgcmd{diff} to review our changes, until we're 1.338 +satisfied with what we've done and arrive at a natural stopping point 1.339 +where we want to record our work in a new changeset. 1.340 + 1.341 +The \hgcmd{commit} command lets us create a new changeset; we'll 1.342 +usually refer to this as ``making a commit'' or ``committing''. 1.343 + 1.344 +\subsection{Writing a commit message} 1.345 + 1.346 +When we commit a change, Mercurial drops us into a text editor, to 1.347 +enter a message that will describe the modifications we've made in 1.348 +this changeset. This is called the \emph{commit message}. It will be 1.349 +a record for readers of what we did and why, and it will be printed by 1.350 +\hgcmd{log} after we've finished committing. 1.351 +\interaction{tour.commit} 1.352 + 1.353 +The editor that the \hgcmd{commit} command drops us into will contain 1.354 +an empty line, followed by a number of lines starting with 1.355 +``\texttt{HG:}''. 1.356 +\begin{codesample2} 1.357 + \emph{empty line} 1.358 + HG: changed hello.c 1.359 +\end{codesample2} 1.360 +Mercurial ignores the lines that start with ``\texttt{HG:}''; it uses 1.361 +them only to tell us which files it's recording changes to. Modifying 1.362 +or deleting these lines has no effect. 1.363 + 1.364 +\subsection{Writing a good commit message} 1.365 + 1.366 +Since \hgcmd{log} only prints the first line of a commit message by 1.367 +default, it's best to write a commit message whose first line stands 1.368 +alone. Here's a real example of a commit message that \emph{doesn't} 1.369 +follow this guideline, and hence has a summary that is not readable. 1.370 +\begin{codesample2} 1.371 + changeset: 73:584af0e231be 1.372 + user: Censored Person <censored.person@example.org> 1.373 + date: Tue Sep 26 21:37:07 2006 -0700 1.374 + summary: include buildmeister/commondefs. Add an exports and install 1.375 +\end{codesample2} 1.376 + 1.377 +As far as the remainder of the contents of the commit message are 1.378 +concerned, there are no hard-and-fast rules. Mercurial itself doesn't 1.379 +interpret or care about the contents of the commit message, though 1.380 +your project may have policies that dictate a certain kind of 1.381 +formatting. 1.382 + 1.383 +My personal preference is for short, but informative, commit messages 1.384 +that tell me something that I can't figure out with a quick glance at 1.385 +the output of \hgcmdargs{log}{--patch}. 1.386 + 1.387 +\subsection{Aborting a commit} 1.388 + 1.389 +If you decide that you don't want to commit while in the middle of 1.390 +editing a commit message, simply exit from your editor without saving 1.391 +the file that it's editing. This will cause nothing to happen to 1.392 +either the repository or the working directory. 1.393 + 1.394 +If we run the \hgcmd{commit} command without any arguments, it records 1.395 +all of the changes we've made, as reported by \hgcmd{status} and 1.396 +\hgcmd{diff}. 1.397 + 1.398 +\subsection{Admiring our new handywork} 1.399 + 1.400 +Once we've finished the commit, we can use the \hgcmd{tip} command to 1.401 +display the changeset we just created. This command produces output 1.402 +that is identical to \hgcmd{log}, but it only displays the newest 1.403 +revision in the repository. 1.404 +\interaction{tour.tip} 1.405 +We refer to the newest revision in the repository as the tip revision, 1.406 +or simply the tip. 1.407 + 1.408 +\section{Sharing changes} 1.409 + 1.410 +We mentioned earlier that repositories in Mercurial are 1.411 +self-contained. This means that the changeset we just created exists 1.412 +only in our \dirname{my-hello} repository. Let's look at a few ways 1.413 +that we can propagate this change into other repositories. 1.414 + 1.415 +\subsection{Pulling changes from another repository} 1.416 +\label{sec:tour:pull} 1.417 + 1.418 +To get started, let's clone our original \dirname{hello} repository, 1.419 +which does not contain the change we just committed. We'll call our 1.420 +temporary repository \dirname{hello-pull}. 1.421 +\interaction{tour.clone-pull} 1.422 + 1.423 +We'll use the \hgcmd{pull} command to bring changes from 1.424 +\dirname{my-hello} into \dirname{hello-pull}. However, blindly 1.425 +pulling unknown changes into a repository is a somewhat scary 1.426 +prospect. Mercurial provides the \hgcmd{incoming} command to tell us 1.427 +what changes the \hgcmd{pull} command \emph{would} pull into the 1.428 +repository, without actually pulling the changes in. 1.429 +\interaction{tour.incoming} 1.430 +(Of course, someone could cause more changesets to appear in the 1.431 +repository that we ran \hgcmd{incoming} in, before we get a chance to 1.432 +\hgcmd{pull} the changes, so that we could end up pulling changes that we 1.433 +didn't expect.) 1.434 + 1.435 +Bringing changes into a repository is a simple matter of running the 1.436 +\hgcmd{pull} command, and telling it which repository to pull from. 1.437 +\interaction{tour.pull} 1.438 +As you can see from the before-and-after output of \hgcmd{tip}, we 1.439 +have successfully pulled changes into our repository. There remains 1.440 +one step before we can see these changes in the working directory. 1.441 + 1.442 +\subsection{Updating the working directory} 1.443 + 1.444 +We have so far glossed over the relationship between a repository and 1.445 +its working directory. The \hgcmd{pull} command that we ran in 1.446 +section~\ref{sec:tour:pull} brought changes into the repository, but 1.447 +if we check, there's no sign of those changes in the working 1.448 +directory. This is because \hgcmd{pull} does not (by default) touch 1.449 +the working directory. Instead, we use the \hgcmd{update} command to 1.450 +do this. 1.451 +\interaction{tour.update} 1.452 + 1.453 +It might seem a bit strange that \hgcmd{pull} doesn't update the 1.454 +working directory automatically. There's actually a good reason for 1.455 +this: you can use \hgcmd{update} to update the working directory to 1.456 +the state it was in at \emph{any revision} in the history of the 1.457 +repository. If you had the working directory updated to an old 1.458 +revision---to hunt down the origin of a bug, say---and ran a 1.459 +\hgcmd{pull} which automatically updated the working directory to a 1.460 +new revision, you might not be terribly happy. 1.461 + 1.462 +However, since pull-then-update is such a common thing to do, 1.463 +Mercurial lets you combine the two by passing the \hgopt{pull}{-u} 1.464 +option to \hgcmd{pull}. 1.465 +\begin{codesample2} 1.466 + hg pull -u 1.467 +\end{codesample2} 1.468 +If you look back at the output of \hgcmd{pull} in 1.469 +section~\ref{sec:tour:pull} when we ran it without \hgopt{pull}{-u}, 1.470 +you can see that it printed a helpful reminder that we'd have to take 1.471 +an explicit step to update the working directory: 1.472 +\begin{codesample2} 1.473 + (run 'hg update' to get a working copy) 1.474 +\end{codesample2} 1.475 + 1.476 +To find out what revision the working directory is at, use the 1.477 +\hgcmd{parents} command. 1.478 +\interaction{tour.parents} 1.479 +To update the working directory to a particular revision, give a 1.480 +revision number or changeset~ID to the \hgcmd{update} command. 1.481 +\interaction{tour.older} 1.482 +If you omit an explicit revision, \hgcmd{update} will update to the 1.483 +tip revision, as shown by the second call to \hgcmd{update} in the 1.484 +example above. 1.485 + 1.486 +\subsection{Pushing changes to another repository} 1.487 + 1.488 +Mercurial lets us push changes to another repository, from the 1.489 +repository we're currently visiting. As with the example of 1.490 +\hgcmd{pull} above, we'll create a temporary repository to push our 1.491 +changes into. 1.492 +\interaction{tour.clone-push} 1.493 +The \hgcmd{outgoing} command tells us what changes would be pushed 1.494 +into another repository. 1.495 +\interaction{tour.outgoing} 1.496 +And the \hgcmd{push} command does the actual push. 1.497 +\interaction{tour.push} 1.498 +As with \hgcmd{pull}, the \hgcmd{push} command does not update the 1.499 +working directory in the repository that it's pushing changes into. 1.500 +(Unlike \hgcmd{pull}, \hgcmd{push} does not provide a \texttt{-u} 1.501 +option that updates the other repository's working directory.) 1.502 + 1.503 +What happens if we try to pull or push changes and the receiving 1.504 +repository already has those changes? Nothing too exciting. 1.505 +\interaction{tour.push.nothing} 1.506 + 1.507 +\subsection{Sharing changes over a network} 1.508 + 1.509 +The commands we have covered in the previous few sections are not 1.510 +limited to working with local repositories. Each works in exactly the 1.511 +same fashion over a network connection; simply pass in a URL instead 1.512 +of a local path. 1.513 +\interaction{tour.outgoing.net} 1.514 +In this example, we can see what changes we could push to the remote 1.515 +repository, but the repository is understandably not set up to let 1.516 +anonymous users push to it. 1.517 +\interaction{tour.push.net} 1.518 + 1.519 +%%% Local Variables: 1.520 +%%% mode: latex 1.521 +%%% TeX-master: "00book" 1.522 +%%% End: