git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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