Re: [PATCH 1/3] fetch: add --allow-local option

Felipe Contreras <felipe.contreras@gmail.com> writes:

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.