From: Junio C Hamano <gitster@pobox.com>
To: Johan Herland <johan@herland.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs
Date: Tue, 07 May 2013 15:20:45 -0700 [thread overview]
Message-ID: <7vppx2ig8y.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CALKQrgctyZGf2z+=+qjcW-s0uyVCqw01pv6X2NG+8yyC3FoTvQ@mail.gmail.com> (Johan Herland's message of "Tue, 7 May 2013 23:52:59 +0200")
Johan Herland <johan@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.
next prev parent reply other threads:[~2013-05-07 22:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-04 23:55 [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs Johan Herland
2013-05-04 23:55 ` [PATCH 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin Johan Herland
2013-05-05 11:56 ` Bert Wesarg
2013-05-06 17:52 ` Junio C Hamano
2013-05-07 18:49 ` Johan Herland
2013-05-07 18:54 ` [PATCHv2 1/3] t1514: Add tests of shortening refnames in strict/loose mode Johan Herland
2013-05-07 18:54 ` [PATCHv2 2/3] t1514: Demonstrate failure to correctly shorten "refs/remotes/origin/HEAD" Johan Herland
2013-05-07 18:54 ` [PATCHv2 3/3] shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin Johan Herland
2013-05-07 21:03 ` [PATCH 1/7] shorten_unambiguous_ref(): Allow " Junio C Hamano
2013-05-07 21:31 ` Junio C Hamano
2013-05-07 22:03 ` Johan Herland
2013-05-07 22:06 ` Junio C Hamano
2013-05-07 22:37 ` Johan Herland
2013-05-04 23:55 ` [PATCH 2/7] t7900: Start testing usability of namespaced remote refs Johan Herland
2013-05-07 1:29 ` Junio C Hamano
2013-05-07 21:52 ` Johan Herland
2013-05-07 22:20 ` Junio C Hamano [this message]
2013-05-04 23:55 ` [PATCH 3/7] t7900: Demonstrate failure to expand "$remote/$branch" according to refspecs Johan Herland
2013-05-07 1:30 ` Junio C Hamano
2013-05-04 23:55 ` [PATCH 4/7] refs.c: Refactor rules for expanding shorthand names into full refnames Johan Herland
2013-05-07 1:36 ` Junio C Hamano
2013-05-04 23:55 ` [PATCH 5/7] refs.c: Refactor code for shortening full refnames into shorthand names Johan Herland
2013-05-07 1:44 ` Junio C Hamano
2013-05-04 23:55 ` [PATCH 6/7] refname_match(): Caller must declare if we're matching local or remote refs Johan Herland
2013-05-07 1:48 ` Junio C Hamano
2013-05-04 23:55 ` [PATCH 7/7] refs.c: Add rules for resolving refs using remote refspecs Johan Herland
2013-05-05 4:28 ` [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs Junio C Hamano
2013-05-05 9:59 ` Johan Herland
2013-05-05 19:02 ` Junio C Hamano
2013-05-05 22:26 ` Johan Herland
2013-05-05 22:36 ` Junio C Hamano
2013-05-06 1:02 ` Santi Béjar
2013-05-06 1:04 ` Santi Béjar
2013-05-06 17:11 ` Junio C Hamano
2013-05-06 19:17 ` Santi Béjar
2013-05-06 17:06 ` Junio C Hamano
2013-05-06 17:20 ` Junio C Hamano
2013-05-06 23:42 ` Johan Herland
2013-05-07 2:11 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vppx2ig8y.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).