[RFD/PATCH 0/5] Improving the search for remote-tracking branches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]