Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> The 'base' branch will be set each time you create a branch from another;
> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
"git checkout -t -b foobar mastee" would instead set 'upstream' of
'foobar' to the branch 'master' of remote '.' (the current one).
This 'base' is a new mechanism to explicitly say "The upstream of
this branch lives locally" by not setting "branch.foobar.remote".
> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will
> pick the right branch to rebase unto, even if you have no 'upstream'
> configured.
Surely you can teach rebase to pay attention to 'base' and achieve
that. But you can already do so with upstream, so this is not an
advertisement of a 'plus', but rather a lack of 'minus' (which is
not a bad thing at all).
> This way 'git fetch' will keep picking 'origin', and other commands that make
> use of 'upstrem' would be undisturbed.
And this is the true plus, because 'git fetch' with the current
"setting a local base using the same upstream mechanism to point at
a branch of _this_ repository, indirectly setting the upstream
_repository_ for this branch to the current repository" will end up
making you fetch from yourself, which is not very interesting.
So I think I understand your itch and I agree that it is a valid
one.
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.
--
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