From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:11
Steven Grimm [off-list ref] writes:
Junio C Hamano wrote:
quoted
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.
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
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:43:11
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
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