On Tue, Oct 12, 2010 at 1:39 PM, Ian Hinder ian.hinder@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@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
- Pushing your commits to the remote repository as soon as you make
them (though this kind of defeats the purpose of distributed version control).
- 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