Johan Herland <jo...@herland.net> writes: > That said, I could have a go at using "refs/peers/*" instead of > "refs/remotes/*", and see how that works out.
Hmm, I had "refs/track/" in mind. Perhaps "peers" may work as well. > If it sticks, how pervasive do we want this renaming to be? I guess we > don't want to rename the "git remote" command to "git peer" just > yet. If we were to do this, I would expect that the transition would be similar to the way we introduced the separate remote layout. The effort was started at around v1.3.0 era and we allowed the users to choose the layout when they make a new clone for quite some time, until we made it the default at v1.5.0 boundary, IIRC. Let the user opt into using the new layout first, and then if the new layout turns out to be vastly more useful than the current one, then the userbase will welcome it as the new default (and otherwise, it won't become the new default). We _should_ be able to tell the layout being used by checking which of refs/peers/ or refs/remotes/ is populated, but I do not mind if we added core.remoteLayout configuration variable that explicitly tells us which, if such an explicit clue turns out necessary. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
