On Wed, May 15, 2013 at 5:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> I however am not yet convinced if that direction is what you really
>> want go in, though. What should your 'git pull' on that branch do,
>> for example?
>>
>> When you are on foobar and want to integrate with the branch you
>> based your work on (i.e. local 'master'), you can do one of these:
>>
>> $ git pull
>> $ git pull --rebase
>>
>> to "fetch the upstream branch and integrate with it", without having
>> to even care if that upstream branch is from the remote, or happens
>> to be truly local. By making 'git fetch' to go to the remote origin
>> site, what will you be merging (or rebasing on) when you do the
>> above two?
>>
>> Incidentally, I suspect you can do exactly the same thing without
>> introducing a new concept "base" and instead special casing a remote
>> whose URL is "."; you essentially declare that "The upstream of this
>> branch whose branch.$name.remote is set to '.' lives locally", which
>> is not all that different from saying "The upstream of this branch
>> whose branch.$name.base exists lives locally", which is what you
>> seem to be proposing. One of the things this alternative approach
>> would "special case" such remote is probably to cause "git fetch" to
>> ignore such a branch.$name.remote setting and instead go fetch from
>> 'origin', just like your "if there is branch.$name.base, but no
>> branch.$name.remote, fetch will go to 'origin'" does.
>>
>> But it has exactly the same "what happens when you do 'git pull'"
>> problem, so even though it is conceptually a lot simpler, it has the
>> same brokenness.
>
> I do not think of a good way to fix the 'git pull' confusion; the
> desire to 'fetch from the overall upstream repository regardless of
> which branch I am on' is a valid and understandable one, but that
> does not mesh well with "'git pull' is 'git fetch' followed by
> either merge or rebase to integrate the result"
But that is not true. It's only true when merge.defaulttoupstream=true.
> and "git merge or
> git rebase pays attention to the other branch that is specified to
> integrate with". The best we could do might be to simply forbid
> "git pull" if your current branch is marked with branch.$name.base
> but still allow "git fetch".
Why forbid it? Why not leave it as it is?
> The changes that are involved are:
>
> * Do not change anything to @{upstream}'s definition, that is,
> "checkout -t -b A localbranch" will set branch.A.remote to '.',
> and "git log A@{u}..A" will stand for "git log localbranch..A".
Yes, but in addition it would set 'branch.A.base'.
> * Current 'git fetch' pays attention to branch.A.remote when you
> are on branch A, and tries to fetch from there. Stop doing that
> when branch.A.remote is set to '.' (the current repository) and
> let other rules in the current implementation decide what remote
> to fetch from. Also teach it to error out when branch.A.remote is
> set to '.' when a new --forbid-local option is passed.
I don't see the point of --forbid-local, but otherwise yeah.
> Ah, alternatively, instead of adding --forbid-local, we could modify
> the changes for 'git fetch' and 'git pull' to read like this:
>
> * Current 'git fetch' pays attention to branch.A.remote when you
> are on branch A, and tries to fetch from there. Stop doing that
> when branch.A.remote is set to '.' (the current repository) and
> let other rules in the current implementation decide what remote
> to fetch from, unless a new --allow-fetch-from-local option is
> passed.
>
> * Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.
Perhaps.
> If we did this, we can keep the "git pull [--rebase]" as a way to
> integrate with what you specified as your upstream, which is a
> common expectation, without forcing you to say "git fetch origin".
I'm starting to change my mind. Perhaps instead of aiming to change
the behavior 'git rebase', it would make more sense to change the
behavior of 'git push'. So that 'git rebase', 'git fetch' and 'git
pull' all use 'upstream' as is currently the case, but 'git push'
would use something different. That would solve my 'origin/master' vs.
'github/master' distinction. But I would like 'git checkout -b foo
master' to automatically setup 'upstream', and 'git checkout -t -b foo
master' to in addition set this other kind that only affects 'git
push'. This would be a much more intrusive change though.
So, 'branch.A.merge' would become 'branch.A.upstream' and have the
full tracking branch (e.g. 'refs/remotes/github/master'), and
'branch.A.remote' would only affect 'git push'.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html