Re: [RFD] making separate-remote layout easier to use

Josef Weidendorfer [off-list ref] writes:

I am not so sure about this. IMHO, any user expects to see "pu" branch
cloned too after cloning git.git (at least me, and a newbie probably too).

I think you are right that we can keep our sanity without
omitting rewinding ones from the tracked set of branches.  In
fact, remotes/origin/* hierarchy are not to be checked out
directly anyway, even after we do the "bare SHA-1 stored in
$GIT_DIR/HEAD" update -- that should give you a read-only
checkout that you cannot commit on top of.  As long as we warn
users who try to merge from these rewinding branches, there is
no reason not to track them.

As said, the real problem begins when the user tries to branch off her
own local branch from "pu". At this point, "git branch" or
"git checkout -b ..." should warn the user that he has to expect troubles
when branching off from such a branch, and only allow it with a
"--force" option.

That is true if you make "git branch my-pu remotes/origin/pu" to
somehow set up the default merge source of "my-pu" branch to be
remotes/origin/pu to encourage merging from it.

I am still not convinced it is a valid assumption that a branch
often want to merge from the branch it was forked off of, and
even less so that "git branch" and "git checkout -b" are the
places to do that configuration.

But for the sake of discussion let's pretend for now that it
were a good idea.  If we know remotes/origin/pu is expected to
be rewound, the logic that configures "my-pu" to merge from the
fork origin should be able to notice that situation, and refrain
from doing the configuration, to prevent the user from issuing
"git pull" without saying "from where", which can be done with
your merge.stopsansdefault option in your other message.