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

[Eric Seidel]

I did some searching online and it seems that 'git pull' is the standard usage as opposed to 'git pull -a'.
Pull is supposed to fetch the changes from the remote repository and then merge them with the working
copy, so unless there is a conflict I don't know why your local copy wouldn't be updated. That being said, it
seems the -a option is unnecessary, so I'll remove it unless someone objects.

Eric


On Oct 12, 2010, at 3:35 PM, Ian Hinder wrote:

> 
> On 12 Oct 2010, at 21:14, Erik Schnetter wrote:
> 
>> On Tue, Oct 12, 2010 at 1:39 PM, Ian Hinder <ian.hinder at aei.mpg.de>  
>> wrote:
>>> 
>>> 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.
>> 
>> I did not have any local changes, neither uncommitted, nor any local
>> commits. This is a local, vanilla copy of the official repository. I
>> checked it out with GetComponents, and updated it several times with
>> GetComponents. I keep a vanilla copy of the Einstein Toolkit around
>> just for testing; I have other checkouts where I develop and make
>> changes.
>> 
>> I had this problem both with Kranc and CTGamma.
>> 
>> Do others see the same problem?
> 
> I have not seen this yet - I don't tend to use GetComponents to do  
> updates.  Instead I use svn and git directly.
> 
>> 
>> -erik
>> 
>>> 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.
>> 
>> -erik
>> 
>> -- 
>> Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/
> 
> -- 
> Ian Hinder
> ian.hinder at aei.mpg.de
> 
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users