From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: johan@herland.net
Subject: [RFD/PATCH 0/5] Improving the search for remote-tracking branches
Date: Fri, 19 Apr 2013 08:20:37 +0200 [thread overview]
Message-ID: <1366352442-501-1-git-send-email-johan@herland.net> (raw)
Hi,
The following patch series has three uncontroversial patches (I hope)
to improve the DWIM behavivor "git checkout foo", followed by two more
experimental patches meant to trigger discussion about how Git decides
on what is a remote-tracking branch, and what is not:
The first three patches concern the DWIMming of "git checkout foo" into
"git checkout -b foo --track refs/remotes/$remote/foo". This DWIMming
depends on finding exactly _one_ remote "$remote" having a remote-
tracking branch called "foo". Currently we find remote-tracking branches
by pattern-matching refs against "refs/remotes/*/foo", but instead we
should look at the configured refspecs to find the real set of remote-
tracking branch candidates. This fixes the DWIM behavior when the user
has tweaked refspecs to place remote-tracking branches elsewhere (e.g.
refs/remotes/$remote/heads/foo). The argument is explained more closely
in patch #3.
The remaining two patches tries to apply the same argument to the
-t/--track argument to checkout/branch: This option takes a remote-
tracking branch (or a local branch) as argument, but validating this
argument is currently done by a simple match against refs/remotes/*
(or refs/heads/*). By the same reasoning as above, we should instead
look at the configured refspecs to determine whether the argument is
a valid remote-tracking branch. However, as shown in the final patch,
this would break a few tests where we currently try to --track refs
that are not "proper" remote-tracking branches (in that they do not
correspond to a refspec of some remote).
- Should we simply "fix" these tests (t3200.39, t7201.24, t9114.*), and
_require_ that all remote-tracking branches must have corresponding
refspecs configured?
- Are there valid real-world use cases that would be broken by such a
requirement?
- Is it preferable to stop after patch #4, and accept the superset of
refs/remotes/* and refspec-matching refs as valid remote-tracking
branches?
Have fun! :)
...Johan
Johan Herland (5):
t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
t2024: Show failure to use refspec when DWIMming remote branch names
checkout: Use remote refspecs when DWIMming tracking branches
branch.c: Look up refspecs to validate tracking branches
RFD: Disallow out-of-refspec refs within refs/remotes/* to be used as upstream
Documentation/git-checkout.txt | 6 +-
branch.c | 17 +++++-
builtin/checkout.c | 42 +++++++-------
t/t2024-checkout-dwim.sh | 116 +++++++++++++++++++++++++++++++++++++++
t/t3200-branch.sh | 2 +-
t/t7201-co.sh | 2 +-
t/t9114-git-svn-dcommit-merge.sh | 8 +--
7 files changed, 163 insertions(+), 30 deletions(-)
create mode 100755 t/t2024-checkout-dwim.sh
--
1.8.1.3.704.g33f7d4f
next reply other threads:[~2013-04-19 6:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 6:20 Johan Herland [this message]
2013-04-19 6:20 ` [RFD/PATCH 1/5] t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>' Johan Herland
2013-04-19 6:20 ` [RFD/PATCH 2/5] t2024: Show failure to use refspec when DWIMming remote branch names Johan Herland
2013-04-19 6:20 ` [RFD/PATCH 3/5] checkout: Use remote refspecs when DWIMming tracking branches Johan Herland
2013-04-19 19:44 ` Junio C Hamano
2013-04-20 8:05 ` Johan Herland
2013-04-19 6:20 ` [RFD/PATCH 4/5] branch.c: Look up refspecs to validate " Johan Herland
2013-04-19 6:20 ` [RFD/PATCH 5/5] RFD: Disallow out-of-refspec refs within refs/remotes/* to be used as upstream Johan Herland
2013-04-19 19:51 ` 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=1366352442-501-1-git-send-email-johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
/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).