[Users] Git problem: "git pull" vs. "git pull -a"?
Ian Hinder
ian.hinder at aei.mpg.de
Tue Oct 12 14:35:02 CDT 2010
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
More information about the Users
mailing list