Git branching & pulling

Hello,

I'm having trouble understanding branching and pull.

Using git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git I can create a branch off the master and do a pull:

wink@ic2d1:~/linux/linux-2.6$ git-checkout master Switched to branch "master" wink@ic2d1:~/linux/linux-2.6$ git-checkout -b test Switched to a new branch "test" wink@ic2d1:~/linux/linux-2.6$ git-pull Already up-to-date.

But from some reason using git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git the following happens

wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout master
Already on branch "master"
wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout -b test
Switched to a new branch "test"
wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull
Warning: No merge candidate found because value of config option
         "branch.test.merge" does not match any remote branch fetched.
No changes.

What I notice is that in kvm.git that .git/remotes is empty while on linux-2.6.git .git/remotes has origin and it contains:

URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Pull: refs/heads/master:refs/heads/origin

Another difference is that the .git/config file of kvm.git has quite a few items:

[core]
 repositoryformatversion = 0
 filemode = true
 bare = false
 logallrefupdates = true
[remote "origin"]
 url = git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
 fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
 remote = origin
 merge = refs/heads/master

While linux-2.6.git is quite sparse:

[core]
        repositoryformatversion = 0
        filemode = true

Could someone give me some insight or point me at a url or doc that could shed some light on what is happening and why git-pull doesn't work on kvm.git.

Thanks,

Wink Saville

On Fri, May 18, 2007 at 10:40:17PM -0700, Wink Saville wrote:

The differences you describe are almost certainly due to differences in the git version, not the cloned repository. Are you sure git wasn't ugpraded between the two tests?

--b.

"Wink Saville" <wink@saville.com> writes:

DEFAULT BEHAVIOUR section of

    http://www.kernel.org/pub/software/scm/git/docs/git-pull.html 

would be the place to start. Recent git-clone (post 1.5.0, I think) prepares the following configuration variables for you by default:

        remote.origin.url
        remote.origin.fetch
	branch.master.remote
        branch.master.merge

but repositories created by older git-clone didn't.

Junio C Hamano <junkio@cox.net> writes:

	/me says "oops I did not finish the sentence".

but repositories created by older git-clone didn't get these configuration variables set. If you set them appropriately, taking example of your other repository (and probably you would also want to remove .git/remotes/origin while you are at it), you can omit saying which branch to pull from where.

I personally never understood why people would just want to say "git pull" without saying anything else, but what described in the DEFAULT BEHAVIOUR section is how it works.

Junio C Hamano wrote:

I do that all the time, e.g. when I'm syncing the satellite repo on my laptop with the mothership repo in my account on my company's server. The satellite only ever talks to the mothership and I am always interested in pulling down all the changes I've committed to the mothership during the day. So there's really no need to specify anything; I always want to keep the two fully in sync, and there's never any question about where I'm pulling from.

I do a plain "git pull" in my clone of git.git too. I want all the latest updates and I'm only ever fetching them from the official git repo.

I can certainly imagine that if I were an integrator in charge of a master repo, I'd always want to explicitly pull from particular places.

-Steve

Steven Grimm <koreth@midwinter.com> writes:

Ah, if you ever interact with only single remote repository, then that is certainly a valid reason not to say anything else.

And if you ever interact with only single branch of a single remote repository while on one branch, the current config scheme would let you do that on any branch.

For reference my git version:

wink@ic2d1:~/linux/kvm-linux-2.6$ git --version git version 1.5.2.rc0.g520d

This is very close to my situation, except in the mothership is linux-2.6.git, kvm.git or git.git. So I have two primary objectives, first periodically synchronize my repository with the remotes. Second, synchronize my branches with their "remotes".

My expectations are that when I'm on a branch and do a git-pull with no parameters I should "fetch" from that branches "remotes" and "merge" into the current branch. This is how linus's repo seems to work.

But with kvm.git it appears I need to be quite explicit:

wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout -b test Switched to a new branch "test" wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull fatal: 'master': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly Cannot get the repository state from master wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull . error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Already up-to-date. wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull . master Already up-to-date. wink@ic2d1:~/linux/kvm-linux-2.6$

So to get consistent behavior it seems I should always use the two parameter form. But the behavior with no parameters was very convenient and less error prone as the branch should always know from where it was cloned:)

Here is another experiment cloning a local repo created with 1.5.2-rc0 where tried git-pull's:

wink@ic2d1:~$ git-clone testgit testgit-clone
Initialized empty Git repository in /home/wink/testgit-clone/.git/
remote: Generating pack...
remote: Done counting 6 objects.
remote: Deltifying 6 objects...
remote: /6) done/6) done
remote: Total 6 (delta 0), reused 0 (delta 0)
Indexing 6 objects...
 100% (6/6) done

wink@ic2d1:~$ cd testgit-clone/
wink@ic2d1:~/testgit-clone$ git-pull
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull .
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull ../testgit
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull ../testgit master
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-checkout -b test master
Switched to a new branch "test"
wink@ic2d1:~/testgit-clone$ git-pull .
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull . master
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull
Warning: No merge candidate found because value of config option
         "branch.test.merge" does not match any remote branch fetched.
No changes.
wink@ic2d1:~/testgit-clone$

Why did last git-pull generate the warning, this seems wrong?

Regards,

Wink Saville

On Saturday 19 May 2007, Wink Saville wrote:

Because git does not know what to merge; there is no config entry for "branch.test.merge", as the warning says. How would you reword this warning to make it easier to understand?

But from your question, I assume that you expected git to have a "branch.test.merge" setting. What do you expect it to do? And why?

Is my assumption correct that you want the last command to be equivalent to "git-pull . master"? And my further assumption, that you want this because you expect "git pull" to default to merging changes from its upstream (also when the upstream is local)?

Creation of a branch from another local one never has created "branch.x.remote" or "branch.x.merge" entries. I am not even sure that setting "branch.x.remote" to "." is working in the current version.

BTW: There was some old behavior of "git pull" to always pull the master
branch from remote "origin" without any further parameters. I suppose that
you did not want this to happen in your example above ?!

Josef

Yes, as you said below that was the old behavior and besides when the branch was created git was told what the upstream was it seems reasonable that it remember that. When I clone a remote it does the right thing it would seem when I make a branch it would behave the same.

I tired to create the appropriate entries and it didn't work, but maybe operator error.

I expected it to pull from its upstream (i.e. the branches parent).

Wink

"Wink Saville" <wink@saville.com> writes:

While "I branched and that means I will always merge from that branch" does not hold true for everybody, we do have an option to make that easy to work in recent git. Look in git-branch documentation and check autosetupmerge configuration option.

I notice that Paolo did not update Documentation/config.txt when he add this feature with 0746d19a; care to send in a patch to correct this?

This patch documents the branch.autosetupmerge config option, adding in commit 0746d19a.

Signed-Off-By: Paolo Bonzini  <bonzini@gnu.org>
---

  config.txt |    7 +++++++
  1 files changed, 7 insertions(+)

	> I notice that Paolo did not update Documentation/config.txt
	> when he add this feature with 0746d19a; care to send in a patch
	> to correct this?
	
	Sure.

	Paolo.

On Wednesday 23 May 2007, Junio C Hamano wrote:

Ah, I stand corrected: I just checked - git already allows to default to even a local upstream for "git pull", not only a remote tracking branch.

Very nice.

What about making "git rebase" without arguments default to the stored upstream?

Josef