Felipe Contreras [off-list ref] writes:
Exactly the same as 'git pull' does right now.
You set
[branch 'foobar']
base = refs/heads/master
then 'git pull [--rebase]' will go to 'origin' due to the default,
but then what branch from the 'origin' are you integrating with?
Do you mean you are also setting both remote and upstream, perhaps
like this, for all of your branches?
[remote "origin"]
url = github.com:maintainer/hisproject
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "github"]
url = github.com:felipec/myproject
fetch = +refs/heads/*:refs/remotes/github/*
[branch 'foobar']
base = refs/heads/master
remote = github ;# or is it origin???
upstream = refs/heads/foobar
Then your 'git pull' will fetch from remote 'origin' and integrate
with its 'foobar' and 'push' may go to update 'foobar' at 'github'.
Perhaps that is what you meant.
'base' has absolutely nothing to do with pulling or pushing.
I agree it shouldn't have anything to do with pushing, but given
that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with
what you 'git fetch', introducing something that 'merge' or 'rebase'
pays attention to that does not have anything to do with 'pull'
sounds like it breaks existing end user expectation.
But that does not mean it is a bad idea. The behaviour changes only
when you have branch.$name.base, so I suspect that we do not need to
worry about "what if the user has both?" case you mentioned in your
first message.
I think I misunderstood what you meant. If it is the norm to have
both base and upstream/remote in branch.$name (as opposed to "have
only branch.$name.base and not branch.$name.remote to force fetch to
go to the default 'origin'), then 'git pull' will not break and I
can see how many things would work naturally (admittedly I can only
say 'many things', not 'everything', at this point, as I haven't
thought things through).
On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
Exactly the same as 'git pull' does right now.
You set
[branch 'foobar']
base = refs/heads/master
then 'git pull [--rebase]' will go to 'origin' due to the default,
but then what branch from the 'origin' are you integrating with?
The same as if you didn't have 'branch.foobar.base': none. You get an
error because there's no upstream.
Do you mean you are also setting both remote and upstream, perhaps
like this, for all of your branches?
[remote "origin"]
url = github.com:maintainer/hisproject
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "github"]
url = github.com:felipec/myproject
fetch = +refs/heads/*:refs/remotes/github/*
[branch 'foobar']
base = refs/heads/master
remote = github ;# or is it origin???
upstream = refs/heads/foobar
Then your 'git pull' will fetch from remote 'origin' and integrate
with its 'foobar' and 'push' may go to update 'foobar' at 'github'.
Perhaps that is what you meant.
That's what I described in my example.
quoted
'base' has absolutely nothing to do with pulling or pushing.
I agree it shouldn't have anything to do with pushing, but given
that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with
what you 'git fetch', introducing something that 'merge' or 'rebase'
pays attention to that does not have anything to do with 'pull'
sounds like it breaks existing end user expectation.
But it's already broken.
'git pull' is not the same as 'git fetch'+'git merge'. That *only*
works when merge.defaulttoupstream is set.
But that does not mean it is a bad idea. The behaviour changes only
when you have branch.$name.base, so I suspect that we do not need to
worry about "what if the user has both?" case you mentioned in your
first message.
Indeed. It wouldn't be an intrusive change; it would only affect 'git
rebase', and nothing more.
But I'm wondering if the behavior of 'git fecth' should change as
well. And in fact it should be the other way around.
I think I misunderstood what you meant. If it is the norm to have
both base and upstream/remote in branch.$name (as opposed to "have
only branch.$name.base and not branch.$name.remote to force fetch to
go to the default 'origin'), then 'git pull' will not break and I
can see how many things would work naturally (admittedly I can only
say 'many things', not 'everything', at this point, as I haven't
thought things through).
But I think the norm would be to have only 'base', because a lot of
people don't manually set an upstream branch.
In the end it all boils down to; which is the upstream
'origin/master', or 'github/master'? Well, it is 'origin/master', so
'upstream' should point there, but I don't want to push to the
'upstream', I want to push somewhere else by default.
--
Felipe Contreras