Re: [PATCH] clone: fix refspec on "--single-branch" option
Junio C Hamano writes:
> 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.
>
> 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.
Along the lines of this, perhaps.
builtin/clone.c | 16
1 file changed, 16 insertions(+)
diff --git i/builtin/clone.c w/builtin/clone.c
index 5e8f3ba..c9e099d 100644
--- i/builtin/clone.c
+++ w/builtin/clone.c
@@ -853,6 +853,22 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
"refs/heads/master");
}
+ if (option_single_branch) {
+ /* Fix up the refspec for fetch */
+ strbuf_reset(&value);
+ if (!remote_head_points_at)
+ strbuf_addf(&value, "HEAD");
+ else
+ strbuf_addf(&value, "%s:%s%s",
+ remote_head_points_at->name,
+ branch_top.buf,
+ skip_prefix(remote_head_points_at->name,
"refs/heads/"));
+
+ strbuf_reset(&key);
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+ git_config_set_multivar(key.buf, value.buf, NULL, 1);
+ }
+
if (is_local)
clone_local(path, git_dir);
else if (refs && complete_refs_before_fetch)
--
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
Re: [PATCH] clone: fix refspec on "--single-branch" option
Nguyen Thai Ngoc Duy writes: > On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano wrote: > >> 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. You first have to think ;-). I would say there are two kinds of users. - To the simplistic ones who fear the power of configuration, we can simply tell "You don't. Use 'single' when you want to keep working with the single branch. If you want full, reclone, and migrate your work from the single one by fetching from it to the full clone before discarding the single one". - To the ones who wants to take the full advantage of flexibility of configuration, we can tell "remotes.$name.fetch configuration is your friend. Do whatever you want to do with it, but here are two hints". The hints would cover the case to revert to the default refspec, and the case to add another specific branch. These days, with "git config" and "git remote" wrappers, I do not particularly see a need to fear the power of configuration, though. -- 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
Re: [PATCH] clone: fix refspec on "--single-branch" option
On Fri, Sep 14, 2012 at 3:10 PM, Nguyen Thai Ngoc Duy wrote:
> On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano wrote:
>> Junio C Hamano 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.
>
$ git remote set-branches "*"
> 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.
>
Such an advice when using "--single-branch" is a good idea, i think.
Something like "The remote is configured to fetch only branch .
If you want to fetch all branches, use "git remote set-branches "*""
or something like that.
>> 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
--
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
Re: [PATCH] clone: fix refspec on "--single-branch" option
On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano wrote:
> Junio C Hamano 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.
--
Duy
--
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
Re: [PATCH] clone: fix refspec on "--single-branch" option
Junio C Hamano 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.
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
Re: [PATCH] clone: fix refspec on "--single-branch" option
Ralf Thielow writes:
> After using "git clone" with the "--single-branch"
> option, the configured refspec for this repo was
> "+refs/heads/*:refs/remotes/origin/*".
> After fetching changes from this repo again, it'll
> receive all refs instead of the single ref which
> was used in "--single-branch". Fixing the refspec
> that it just contains the ref of the branch which
> was cloned.
>
> Signed-off-by: Ralf Thielow
> ---
> builtin/clone.c | 5 -
> 1 Datei geändert, 4 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 5e8f3ba..3e74d55 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -754,7 +754,10 @@ int cmd_clone(int argc, const char **argv, const char
> *prefix)
> strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
> }
>
> - strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
> + if (option_single_branch)
> + strbuf_addf(&value, "+%s%s:%s%s", src_ref_prefix,
> option_branch, branch_top.buf, option_branch);
> + else
> + strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
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.
--
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
