Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> 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. - 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