Re: [PATCH] clone: fix refspec on --single-branch option
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.
--
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 3:10 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
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.
$ git remote set-branches remote *
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 remote is configured to fetch only branch branch.
If you want to fetch all branches, use git remote set-branches remote *
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
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com 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
Ralf Thielow ralf.thie...@gmail.com 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 ralf.thie...@gmail.com
---
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
