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
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