Git branching & pulling

Git branching & pulling

[Wink Saville]

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

Re: Git branching & pulling

[J. Bruce Fields]

On Fri, May 18, 2007 at 10:40:17PM -0700, Wink Saville wrote:
> 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.

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.

Re: Git branching & pulling

[Junio C Hamano]

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

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

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.

Re: Git branching & pulling

[Junio C Hamano]

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

> "Wink Saville" <wink@saville.com> writes:
>
>> 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.
>
> 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.

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

Re: Git branching & pulling

[Steven Grimm]

Junio C Hamano wrote:
> 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.
>   

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

Re: Git branching & pulling

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> Junio C Hamano wrote:
>> 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.
>>
>
> 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.

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.

Re: Git branching & pulling

[Wink Saville]

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

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

Re: Git branching & pulling

[Josef Weidendorfer]

On Saturday 19 May 2007, Wink Saville wrote:
> 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?

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

Re: Git branching & pulling

[Wink Saville]

>
> 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)?

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.

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

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

> 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 ?!
>

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

Wink

Re: Git branching & pulling

[Junio C Hamano]

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

>> 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.
>
> I tired to create the appropriate entries and it didn't work,
> but maybe operator error.
>
>> 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 ?!
>
> I expected it to pull from its upstream (i.e. the branches parent).

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?

[PATCH] Document branch.autosetupmerge.

[Paolo Bonzini]

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.

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 179cb17..de3c276 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -280,4 +280,11 @@ apply.whitespace::
  	Tells `git-apply` how to handle whitespaces, in the same way
  	as the '--whitespace' option. See gitlink:git-apply[1].

+branch.autosetupmerge::
+	Tells `git-branch' and `git-checkout' to setup new branches
+	so that gitlink:git-pull[1] will appropriately merge from that
+	remote branch.  Note that even if this option is not set,
+	this behavior can be chosen per-branch using the `--track`
+	and `--no-track` options.  This option defaults to false.
+
  branch.<name>.remote::

Re: Git branching & pulling

[Josef Weidendorfer]

On Wednesday 23 May 2007, Junio C Hamano wrote:
> "Wink Saville" <wink@saville.com> writes:
> 
> >> 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.
> >
> > I tired to create the appropriate entries and it didn't work,
> > but maybe operator error.
> >
> >> 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 ?!
> >
> > I expected it to pull from its upstream (i.e. the branches parent).
> 
> 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.

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