From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: johan@herland.net, gitster@pobox.com
Subject: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs
Date: Sun, 5 May 2013 01:55:42 +0200 [thread overview]
Message-ID: <1367711749-8812-1-git-send-email-johan@herland.net> (raw)
The "$remote/$branch" syntax can be interpreted in two subtly different
ways:
1. A shorthand name for the remote-tracking branch corresponding to a
specific $branch from a specific $remote.
2. A refname fragment, which - when appended to "refs/remotes/" -
yields the remote-tracking branch corresponding to a specific
$branch from a specific $remote.
For the current default/conventional refspecs, both interpretations are
true and equally valid. However, when configuring non-default refspecs
(such as the +refs/heads/*:refs/remotes/origin/heads/*), it becomes
obvious that the current code follows the latter interpretation: The
"$remote/$branch" shorthand will no longer work, and you are forced to
use "$remote/heads/$branch" instead.
I argue that the former interpretation is what most users intuitively
expect, and that we should work towards making Git follow the same
interpretation:
Instead of prepending "refs/remotes/" to convert "$remote/$branch" into
a full refname, we should find "$remote" in the repo config, and then
map "refs/heads/$branch" through $remote's fetch refspec(s), to find
the remote-tracking branch that properly corresponds to the specific
$branch in the $remote repo.
This goal is achieved by the final patch in this series, and most of
the preceding patches serve as preliminary changes and refactoring to
support this.
Patch #1 is the exception in that it is a self-contained bugfix for a
scanf-related problem I ran across while working on the patch series.
Patches #2 and #3 introduce a new test intended to verify Git's
usability when working with remote ref namespaces (which rely on
setting up unconventional refspecs). For now, this test is fairly
thin, but it should be expanded as we find more problems with these
kinds of setups.
Patches #4 and #5 are pure refactorings to reorganize the code that
expands shorthand names to full refnames and vice versa. The idea
is to associate the patterns that are used to expand/shorten ref
names with the actual function that does the expansion/shortening,
so that we can later add patterns that uses different expand/shorten
functions.
Patch #6 teaches Git to realize when - in the context of communication
with a remote repo - it's expanding shorthand refs into either local
refnames, or remote refnames. It is important that any expansion rules
relying on local repo configuration are not allowed to expand shorthand
names on behalf of the remote repo.
Finally, patch #7 introduces a new rule and associated expand/shorten
functions mapping "$remote/$branch"-type shorthand names to/from their
remote-tracking branch counterparts, by using the configured refspecs
as described above. This rule is obviously only applied to local refs,
as it would be wrong for a repo to use its local config to dictate a
ref expansion in a remote repo.
The series has been build on recent 'next', and although it also
applies cleanly to v1.8.3-rc1, it will cause a test failure in
t7900, since it depends on the jh/checkout-auto-tracking topic, which
is currently cooking.
Have fun! :)
...Johan
Johan Herland (7):
shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
t7900: Start testing usability of namespaced remote refs
t7900: Demonstrate failure to expand "$remote/$branch" according to refspecs
refs.c: Refactor rules for expanding shorthand names into full refnames
refs.c: Refactor code for shortening full refnames into shorthand names
refname_match(): Caller must declare if we're matching local or remote refs
refs.c: Add rules for resolving refs using remote refspecs
cache.h | 4 -
refs.c | 260 +++++++++++++++++--------
refs.h | 14 ++
remote.c | 15 +-
t/t6300-for-each-ref.sh | 12 ++
t/t7900-working-with-namespaced-remote-refs.sh | 133 +++++++++++++
6 files changed, 342 insertions(+), 96 deletions(-)
create mode 100755 t/t7900-working-with-namespaced-remote-refs.sh
--
1.8.1.3.704.g33f7d4f
next reply other threads:[~2013-05-04 23:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-04 23:55 Johan Herland [this message]
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
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=1367711749-8812-1-git-send-email-johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).