Junio C Hamano wrote: > 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. By the way, I think the backward compatibility option should be simply named --dont-use-separate-remote, or --without-separate-remote, or --no-separate-remote (the last is probably the best choice). > 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. The exception being that with --use-separate-remote you cannot checkout tracking branches to see what it is there (at least for now, but IIRC we want to relax this constraint; i.e. to forbid commiting to non-heads, instead of forbidding checking out), you cannot use it as alternate source (as alternate repo to check from) while still allowing to work on it, and that gitweb doesn't show anything except heads and tags; it doesn't show remotes. By the way, does new "git peek-remote -a ." show anything except refs/heads/, refs/tags/ and refs/remotes (e.g. StGit refs/bases/ and refs/patches/)? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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