<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%===================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_help_format}
%===================================================================

\begin{document}

\begin{labcover}
\labtitle{Help Topic: The Git Pull Command}
\vspace{0.1in}
\labdate{Fall 2024}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Oscar Viquez, oviquezr@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labline
\end{labcover}

\wikidoc{file=Help.GitPull}
\wikidoc{auth=mikerb@mit.edu}

%====================================================================
\section*{The Git \cmd{pull} Command}
%====================================================================

The \cmd{git pull} command lets you refresh your locally checked out
repository with any changes in the repository HEAD on the server. It
also tells you {\em what} has been changed, added, deleted. If a
change has been made to a file you have also changed locally, Git will
try to merge those changes. If unsuccessful, it will report a
conflict. More on this is discussed below.  More info can always be
found by Googling "Git book" and reading the full PDF online
free, or just typing \cmd{git help pull} anytime on the command
line.

%---------------------------------------------------------------------
\subsection*{Basic usage of the \cmd{git pull} command}

The basic syntax for the \cmd{git pull} command is:

\vspace{0.05in}
\begin{consoleverb}
 $ git pull        #(invoked somewhere within previously checked out tree)
\end{consoleverb}
\vspace{0.15in}

\noindent
The \cmd{git pull} command requires a network connection to the
server and perhaps a password if it is not an anonymous read-only
repository. The command may be invoked anywhere in the locally checked
out tree. By default, the update will apply across the entire repository
regardless of where in the tree it is called.

%---------------------------------------------------------------------
\subsection*{Deciphering the output of the \cmd{git pull} command}

In the simplest case, when your locally checked out tree is up to date
with the server, you will see a one-line response like the following:

\vspace{0.1in}
\begin{consoleverb}
 $ git pull
 Already up to date.
\end{consoleverb}
\vspace{0.1in}

\pskip
Beware of the common "gotcha". Two developers both perform an update
and confirm that they have the same version - but their code is
acting differently. This can drive people bonkers. The thing to
remember is that, even though you both have the same version checked out,
one or both of you may have local modifications that you have not yet
checked into the server. Very likely one of these local modifications is
causing the difference in observed behavior. Check for local
modifications using the \cmd{git status} command, discussed in a
separate help topic or in the Git book.

\pskip
\noindent
Here's an example output after an update:

\vspace{0.1in}
\begin{consoleverb}
 $ git pull
 remote: Enumerating objects: 5, done.
 remote: Counting objects: 100% (5/5), done.
 remote: Compressing objects: 100% (2/2), done.
 remote: Total 3 (delta 0), reused 0 (delta 0)
 Unpacking objects: 100% (3/3), 270 bytes | 135.00 KiB/s, done.
 From &lt;server&gt;:&lt;repo&gt;
    66051d7..15a95d0  master     -&gt; origin/master
 Updating 66051d7..15a95d0
 Fast-forward
  Figure.h   | 1 +
  Object.cpp | 0
  Object.h   | 0
  3 files changed, 1 insertion(+)
  create mode 100644 Object.cpp
  create mode 100644 Object.h
\end{consoleverb}
\vspace{0.15in}

\noindent
This indicates that:

\begin{packed_itemize}[1]
\item The file \var{Figure.h} was updated with changes pulled in from the 
server. There was one line of code added to the file.
\item The files \var{Object.h} and \var{Object.cpp} are newly added from 
the server to your local checkout. These sample files are empty, adding zero
new lines of code.
\end{packed_itemize}

If there are any files with {\em uncommitted} local changes which would be
overwritten by a file pulled from the server, the program may inform the user
of this conflict, and instruct the user to commit or stash their changes
before merging changes from the server, to avoid the loss of progress.

\vspace{0.1in}
\begin{consoleverb}
 $ git pull
 remote: Enumerating objects: 5, done.
 remote: Counting objects: 100% (5/5), done.
 remote: Compressing objects: 100% (3/3), done.
 remote: Total 3 (delta 1), reused 0 (delta 0)
 Unpacking objects: 100% (3/3), 281 bytes | 140.00 KiB/s, done.
 From &lt;server&gt;:&lt;repo&gt;
    18aacd8..9bc491a  master     -&gt; origin/master
 Updating 18aacd8..9bc491a
 error: Your local changes to the following files would be overwritten by merge:
   README.md
 Please commit your changes or stash them before you merge.
 Aborting
\end{consoleverb}
\vspace{0.15in}


% %---------------------------------------------------------------------
% \subsection*{Dealing with a conflict after a \cmd{git pull}}

% Git is pretty good at merging two files with separate changes. It usually
% gets things right, and errs on the side of being conservative; sometimes
% it flags as a conflict an issue that is easily resolved when it hits human
% eyes. In the case above, if the file \var{Figure.h} was {\em not} able to
% be merged by the git algorithms, you would have see this instead:

% \vspace{0.1in}
% \begin{consoleverb}
%  $ svn update
%  Updating '.':
%  U    XWFigure.h
%  A    XKObject.h
%  C    XWItems.cpp
%  A    XKObject.cpp
%  Updated to revision 303.
%  Conflict discovered in file 'Items.cpp'.
%  Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
%          (mc) my side of conflict, (tc) their side of conflict,
%          (s) show all options:
% \end{consoleverb}
% \vspace{0.15in}

% \noindent
% The choices are a fairly self-explanatory. I choose (e) most of the time
% unless I just happen to know that my local change is worth discarding,
% in which case I choose (tc). The (m) option puts you into an interactive
% tool that helps you de-conflict. The (df) option just shows you the
% difference between two files. The (p) option just kicks the can down the
% road and leaves the file marked as conflicted. You won't be able to check
% in local changes until that conflict is resolved.

% \pskip

% The one worth special mention is the (e) option. It's probably best to
% deal with any conflicts as they come up, and dealing with them during
% the update process is my own general practice. Selecting the (e)
% option launches an editor in your terminal window. The editor will show
% a file with the conflicts delimited as by example below.

% \vspace{0.1in}
% \begin{consoleverb}
%  &lt;&lt;&lt;&lt;&lt;&lt;&lt; .mine
%  // string fruit = "apples";
%  =======
%  // string fruit = "pears";
%  &gt;&gt;&gt;&gt;&gt;&gt;&gt; .r305
% \end{consoleverb}
% \vspace{0.15in}

% \noindent
% You can resolve the conflict by picking one version of a block of code
% and deleting the other (and the delimiter lines), and saving the file.
% Once you have quit the editor, you are prompted with the same set of
% options with one additional option, the (r) option:

% \vspace{0.1in}
% \begin{consoleverb}
%  Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
%          (r) mark resolved, (mc) my side of conflict,
%          (tc) their side of conflict, (s) show all options:
% \end{consoleverb}
% \vspace{0.15in}

% \noindent
% By choosing the (r) option you are acknowledging to svn that all is
% good from your perspective, for that file. It will then continue with
% the rest of the update.

% %------------------------------------------------------------------
% \subsection*{Configuring SVN with an editor of your choosing}

% Getting back to that issue of launching an editor to resolve conflicts
% as described above. "Which editor?" you may ask. The editor chosen is
% determined by how you have certain environment variables set in your
% shell configuration. It will first look for the value of
% the \var{SVN\_EDITOR} variable, and fall back to the value for
% the \var{EDITOR} environment variable. If these are not set, svn may
% not allow you to select the (e) option.

% \pskip
% \noindent
% If you're a \var{tcsh} user, add the following lines to
% your \var{.cshrc} file, with the editor of your choosing:

% \vspace{0.1in}
% \begin{fileverb}
%   setenv EDITOR 'emacs'
%   setenv SVN_EDITOR 'emacs'
% \end{fileverb}
% \vspace{0.15in}

% \noindent
% If you're a \var{bash} user, add the following lines to
% your \var{.bashrc} file, with the editor of your choosing:

% \vspace{0.1in}
% \begin{fileverb}
%   export EDITOR=emacs
%   ecport SVN_EDITOR=emacs
% \end{fileverb}
% \vspace{0.15in}

% \noindent
% To check the prevailing value of an environment variable, e.g., \var{EDITOR},
% just type this on the command line: \cmd{echo \$EDITOR}.

% \pskip

% \noindent
% (The \var{EDITOR} is also relevant when checking in (committing) code and
% adding a commit comment.)

\end{document}

</pre></body></html>