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" 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".
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".
* 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.
* Teach 'git pull' to pass --forbid-local option to 'git fetch',
and let an error return fail the whole thing.
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'.
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".
--
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