Petr Baudis <pasky@xxxxxxx> writes: >> Even though I fully agree that use-separate-remotes should be >> the default, to the point that I think we do not even >> need a backward compatibility option. People who want to use >> traditional layout for simple one-remote-branch-only project >> would not suffer anyway because 'origin' still means origin in >> the new layout (refs/remotes/origin/HEAD). > > I don't know, we still at least need to keep the functionality for > --bare. I agree --bare should continue to be a "snapshot mirror"; I am not advocating for the removal of the internal implementation detail such as $use_separate_remote variable. However, I think having one sane behaviour is the right thing to do for a clone that prepares a repository with a working tree (including the one made with -n option, which only means "do not do the check-out immediately after cloning" for such a repository). The traditional layout is slightly simpler for a project with the simplest needs (that is, a single upstream repository that has a single 'master' branch), but I do think even that is not an advantage anymore. With the separate-remote layout, git-fetch would still fetch and update the "origin" (although that is now remotes/origin/master which is pointed at by remotes/origin/HEAD) and the user can still refer to it with "origin". Commands "git-pull origin", "git-pull . origin", and "git-merge origin" all will continue to work the same way as before for such a project as in the traditional layout, and that is why I think we do not need backward compatibility flag in this case. - 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