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

[Erik Schnetter]

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?

-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/