Re: [PATCH] clone: fix refspec on "--single-branch" option

On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

Who guarantees at this point in the codepath that option_branch is
set when option_single_branch is non-zero?  Until we talk with the
remote, "clone --single-branch" without an explicit "--branch" will
not learn which branch at the remote we are going to fetch (it will
be their HEAD).

I wonder if this should be more like this:

      if (option_single_branch) {
              if (option_branch)
                      Your patch "+refs/heads/foo:refs/remotes/origin/foo";
              else
                      "HEAD";
        } else {
              Original "+refs/heads/*:refs/remotes/origin/*";
      }

That is, "clone --single-branch" will continue fetching from and
integrating with their HEAD without storing any remote tracking
branch.

Alternatively, if you can move the logic to set up this
configuration further down so that it happens after we talked to the
other side and figured out remote_head_points_at, you could instead
set it up to keep a single remote tracking branch.

That sounds reasonable. I have a question though, what should a user
do when he/she want to fetch all branches again? Messing up with
refspec in config file is not something I would like to do.

Perhaps a heuristic in git-fetch to detect "single branch" situation
and ignore refspec? We could hint people that refspecs are not
followed when remote has more than one branch. They could either fetch
the another branch explicitly, which turns off the heuristic, or turn
off the advice.

Even if you did so, guess_remote_head() may not find any branch when
the other repository's HEAD is detached, so you would need to decide
what to do in such a case, and "fetch and integrate their HEAD
without using any remote tracking branch" may be a reasonable thing
to do in such a case.

-- 
Duy