Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> So that it becomes possible to override the behavior when the remote
> tracked is '.'; if it is, we default back to 'origin'.
I know I was the stupid one who originally suggested this, but I
think this is a wrong direction to go. I do not think it solves
your "I do not want to say 'git fetch origin'" problem.
You do "git checkout -t -b mywork master" because you want to later
be able to conveniently rebase mywork on top of your local master
(i.e. make @{u} notation work for you) [*1*].
What "git checkout -t -b $branch $up" does is to declare that branch
builds on top of $up, which often is some remote tracking branch.
And "git pull [--rebase]" on that $branch is to
(1) make sure $up is available and up to date; and
(2) integrate with $up. The first step is "git fetch" and it
has to go to the repository $up comes from.
If $up is in your local repository (the original "fork mywork from
master in my repository"), the first step ought to be a no-op, and
"git fetch" from the current repository may seem wasteful, but I
think we already have an optimization to make this no-op not to
transfer anything network-wise. There is no justification for it to
go to 'origin' or any other random remote that is different from the
reopsitory $up comes from.
I _think_ the real reason you want a "git fetch" while on "mywork"
to go to 'origin' is because you are building your "master" off of
somebody else's work that comes from 'origin', and you want to check
what has changed to see what you need to rebuild both your "master"
and "mywork" branches on top of. If 'master' were forked from a
remote that is not 'origin', then making "git fetch" ignore '.' and
instead go to 'origin' would not solve anything. For an updated
behaviour to be useful in that workflow, it needs to follow the
inter-branch relationship ("mywork is a fork of master which is a
fork of frotz branch from a remote xyzzy") to see the first remote
repository and fetch from there, instead of blindly fetching from
the 'origin'.
Having said all that, I am not all that sure that it is a good idea
to introduce such an exception for "git fetch" to ignore '.',
regardless of where it goes instead, either the 'origin' or the
first remote repository it finds by recursively finding its
upstreams, to break the consistency at the UI level. It is dubious
if the benefit of convenience to fetch from remote 'xyzzy' that is
an eventual remote of 'mywork' without having to say so outweighs
the cost of additional UI inconsistency, making things harder to
explain to both new and old people.
[Footnote]
*1* Another side effect this has is that in a triangular workflow,
the place you push to may not be the place the branch you
integrate with (i.e. 'master') lives (i.e. '.', your local
repository), and the name you want to push it as may not be the
same as the branch you integrate with (i.e. 'master'), either.
Ram's branch.mywork.pushremote can solve the former (i.e. where
it goes), but not the latter (i.e. to which branch it is pushed),
and that is a valid issue that may need to be addressed.
--
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