[Users] Git problem: "git pull" vs. "git pull -a"?

[Ian Hinder]

On 12 Oct 2010, at 19:48, Erik Schnetter wrote:

> I notice that GetComponents uses the command "git pull -a" instead of
> "git pull" to update existing repositories. I also notice that many of
> my git repositories which I updated via GetComponents have spurious
> merge patches in there, apparently automatically committed by myself,
> merging many versions of "master":
>
> commit 2db16f219702be9b9bbdbe3290cd4ec67f514dbd
> Author: Erik Schnetter <schnetter at cct.lsu.edu>
> Date:   Tue Sep 14 21:54:25 2010 -0500
>
>    Merge branches 'master', 'master', 'master', 'master', 'master'  
> and 'master'
>
> Another problem is that the checked out version of my source tree does
> not change. In addition, the additional patches that have been pulled
> in are marked as "undone" in the staging area, so that my next "git
> commit" would create a patch that undoes them.
>
> What does "git pull -a" do? Is that a bad option? I don't understand
> the description of the git-pull man page; it says:
>
>       -a, --append
>           Append ref names and object names of fetched refs to the  
> existing
>           contents of .git/FETCH_HEAD. Without this option old data in
>           .git/FETCH_HEAD will be overwritten.
>
> Do we need to leave out the "-a" option? Or are my spurious merge
> commits caused by something else? I didn't have any local changes to
> start with.

I don't think the -a is responsible, from the description you give  
above.  These merge commits happen when you make local commits before  
pulling from the remote repository and getting the new commits from  
there.  This is an unavoidable feature of distributed version  
control.  It can be avoided by

1. Pushing your commits to the remote repository as soon as you make  
them (though this kind of defeats the purpose of distributed version  
control).

2. Using "git pull --rebase" instead of "git pull" - this pulls in the  
remote commits and rewrites your commits after them all, as if you had  
made them after the last commit in the remote repo. This can lead to  
conflicts, but they are essentially the same conflicts that you would  
have to have resolved in SVN if you had done an "update" with local  
uncommitted changes.  As always, if you have local changes/commits,  
updating frequently is less painful than updating infrequently as the  
conflicts will be less each time.

An example of using (2) is the VLC project, where they recommend this  
practice (http://wiki.videolan.org/Git#Setting_up_.22git_up.22_.28Tip. 
29).  The only caveat is that because you are rewriting your own  
history, you should make sure that no one else has based a repository  
off yours, as things will get confused then.

-- 
Ian Hinder
ian.hinder at aei.mpg.de