Andreas Ericsson <ae@xxxxxx> writes: > That way the only extra dwimery would be to add "remotes" after > "heads" under .git/refs and accept directory in .git/remotes/ as ref > and tack on '/master' at the end of it as the last option to > search. For a specific branch on an imported remote, one would have to > say "jc/next". This means we still only handle 'master' specially so > we don't introduce any new protected or special names. Two things that holding me back from doing what you suggested are (1) "master" is just a convention and indeed non-negligible number of kernel.org trees have "test" and "release" instead without "master"; (2) I'd really really really want to avoid teaching get_sha1_basic() C-level about .git/remotes/$origin file, even though that function is more of a UI level than the rest of the really core C-level routines. But if I were forced to choose between the above 2, I would probably pick defaulting to "master". The reason I would like to avoid .git/remotes/$origin is because it is designed to be Porcelainish thing. The underlying C-level git-fetch-pack never sees it; instead the information fed to C-level is prepared by the upper layer using that file. As far as I understand, Cogito does not understand it either, except that it ships with bash completion code that reads from filenames there. - : 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