On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to