Re: [PATCH v2 9/9] fetch: allow explicit --refmap to override configuration
On 06/05/2014 08:36 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: I don't have any objection to the option per se. But I do wonder if there's a need to add yet another knob to git just for completeness. Has anyone ever needed this? It is not a good yardstick, as everybody has survived without it since Git's inception. The right question to ask is: would it help new use patterns, or improve existing use patterns? I agree that this feature is pretty esoteric and probably more cognitive load than it's worth. One of your use cases has workarounds shown below. Two possible scenarios I can think of offhand are * using an empty refmap to ensure that your fetch this time is really ephemeral without affecting the longer-term configured remote-tracking branches Doesn't specifying an explicit URL get around the refspecs configured for the remote? E.g., git fetch $(git config remote.github.url) master Or if we had a way to temporarily unset multivalued configuration values (which we may have soon thanks to the GSoC project of Tanay Abhra), one could use git --unset=remote.github.fetch fetch github master * grabbing only a few selected branches out of hundreds, e.g. $ git fetch https://github.com/gitster/git \ --refmap=refs/heads/*:refs/remotes/jch/* maint master next +pu instead of having to spell its long-hand $ git fetch https://github.com/gitster/git \ refs/heads/maint:refs/remotes/jch/maint \ refs/heads/master:refs/remotes/jch/master \ refs/heads/next:refs/remotes/jch/next \ +refs/heads/pu:refs/remotes/jch/pu I'm not quite sure what your goal is here, but if you want to fetch some branches on the fly without setting up a remote, then git -c remote.github.fetch='refs/heads/*:refs/remotes/jch/*' \ fetch https://github.com/gitster/git maint master next +pu should work, no? but there may be more useful scenarios other people can come up with ;-). Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 v2 9/9] fetch: allow explicit --refmap to override configuration
On 14-06-04 06:28 PM, Junio C Hamano wrote: Marc Branchaud mbranch...@xiplink.com writes: Teach the command to pay attention to the --refmap=lhs:rhs command-line options that can be used to override the use of configured remote.*.fetch as the refmap. (Your 0/9 message merely said The new patches at the end clarifies how remote.*.fetch configuration variables are used in two conceptually different ways. so I was not expecting fetch to get a new option.) This is more about conceptual consistency completeness than new and useful addition, in that configured values and the feature they enable ought to be expressible and overridable from the command line options but we so far lacked a way to trigger the do not affect what gets fetched, only affect where they go locally feature, which is offered by the second way to use remote.*.fetch variable. I do not think we absolutely need it and that is why it is at the end as an optional addition. Ah, OK. I don't have any objection to the option per se. But I do wonder if there's a need to add yet another knob to git just for completeness. Has anyone ever needed this? M. -- 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 v2 9/9] fetch: allow explicit --refmap to override configuration
Marc Branchaud marcn...@xiplink.com writes: I don't have any objection to the option per se. But I do wonder if there's a need to add yet another knob to git just for completeness. Has anyone ever needed this? It is not a good yardstick, as everybody has survived without it since Git's inception. The right question to ask is: would it help new use patterns, or improve existing use patterns? Two possible scenarios I can think of offhand are * using an empty refmap to ensure that your fetch this time is really ephemeral without affecting the longer-term configured remote-tracking branches * grabbing only a few selected branches out of hundreds, e.g. $ git fetch https://github.com/gitster/git \ --refmap=refs/heads/*:refs/remotes/jch/* maint master next +pu instead of having to spell its long-hand $ git fetch https://github.com/gitster/git \ refs/heads/maint:refs/remotes/jch/maint \ refs/heads/master:refs/remotes/jch/master \ refs/heads/next:refs/remotes/jch/next \ +refs/heads/pu:refs/remotes/jch/pu but there may be more useful scenarios other people can come up with ;-). -- 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 v2 9/9] fetch: allow explicit --refmap to override configuration
On 14-06-03 06:16 PM, Junio C Hamano wrote:
Since the introduction of opportunisitic updates of remote-tracking
branches, started at around f2690487 (fetch: opportunistically
update tracking refs, 2013-05-11) with a few updates in v1.8.4 era,
the remote.*.fetch configuration always kicks in even when a refspec
to specify what to fetch is given on the command line, and there is
no way to disable or override it per-invocation.
Teach the command to pay attention to the --refmap=lhs:rhs
command-line options that can be used to override the use of
configured remote.*.fetch as the refmap.
(Your 0/9 message merely said The new patches at the
end clarifies how remote.*.fetch configuration variables are used in
two conceptually different ways. so I was not expecting fetch to get a new
option.)
Signed-off-by: Junio C Hamano gits...@pobox.com
---
---
Documentation/fetch-options.txt | 8
Documentation/git-fetch.txt | 3 +++
builtin/fetch.c | 35 ---
t/t5510-fetch.sh| 37 +
4 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 92c68c3..d5c6289 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -72,6 +72,14 @@ endif::git-pull[]
setting. See linkgit:git-config[1].
ifndef::git-pull[]
+--refmap=refspec::
+ When fetching refs listed on the command line, use the
+ specified refspec (can be given more than once) to map the
+ refs to remote-tracking branches, instead of values of
s/values/the values/
+ `remote.*.fetch` configuration variable for the remote
s/variable/variables/
+ repository. See section on Configured Remote-tracking
+ Branches for details.
+
-t::
--tags::
Fetch all tags from the remote (i.e., fetch remote tags
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index d09736a..96c44f9 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -93,6 +93,9 @@ This configuration is used in two ways:
only used to decide _where_ the refs that are fetched are stored
by acting as a mapping.
+The latter use of the configured values can be overridden by giving
For consistency with my suggestions on 8/9:
s/configured values/`remote.repository.fetch` values/
M.
+the `--refmap=refspec` parameter(s) on the command line.
+
EXAMPLES
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 55f457c..dd46b61 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -45,6 +45,8 @@ static struct transport *gsecondary;
static const char *submodule_prefix = ;
static const char *recurse_submodules_default;
static int shown_url = 0;
+static int refmap_alloc, refmap_nr;
+static const char **refmap_array;
static int option_parse_recurse_submodules(const struct option *opt,
const char *arg, int unset)
@@ -69,6 +71,19 @@ static int git_fetch_config(const char *k, const char *v,
void *cb)
return 0;
}
+static int parse_refmap_arg(const struct option *opt, const char *arg, int
unset)
+{
+ ALLOC_GROW(refmap_array, refmap_nr + 1, refmap_alloc);
+
+ /*
+ * git fetch --refmap='' origin foo
+ * can be used to tell the command not to store anywhere
+ */
+ if (*arg)
+ refmap_array[refmap_nr++] = arg;
+ return 0;
+}
+
static struct option builtin_fetch_options[] = {
OPT__VERBOSITY(verbosity),
OPT_BOOL(0, all, all,
@@ -107,6 +122,8 @@ static struct option builtin_fetch_options[] = {
N_(default mode for recursion), PARSE_OPT_HIDDEN },
OPT_BOOL(0, update-shallow, update_shallow,
N_(accept refs that update .git/shallow)),
+ { OPTION_CALLBACK, 0, refmap, NULL, N_(refmap),
+ N_(specify fetch refmap), PARSE_OPT_NONEG, parse_refmap_arg },
OPT_END()
};
@@ -278,6 +295,9 @@ static struct ref *get_ref_map(struct transport
*transport,
const struct ref *remote_refs = transport_get_remote_refs(transport);
if (refspec_count) {
+ struct refspec *fetch_refspec;
+ int fetch_refspec_nr;
+
for (i = 0; i refspec_count; i++) {
get_fetch_map(remote_refs, refspecs[i], tail, 0);
if (refspecs[i].dst refspecs[i].dst[0])
@@ -307,12 +327,21 @@ static struct ref *get_ref_map(struct transport
*transport,
* by ref_remove_duplicates() in favor of one of these
* opportunistic entries with FETCH_HEAD_IGNORE.
*/
- for (i = 0; i transport-remote-fetch_refspec_nr; i++)
- get_fetch_map(ref_map, transport-remote-fetch[i],
- oref_tail, 1);
+ if
Re: [PATCH v2 9/9] fetch: allow explicit --refmap to override configuration
Marc Branchaud mbranch...@xiplink.com writes: Teach the command to pay attention to the --refmap=lhs:rhs command-line options that can be used to override the use of configured remote.*.fetch as the refmap. (Your 0/9 message merely said The new patches at the end clarifies how remote.*.fetch configuration variables are used in two conceptually different ways. so I was not expecting fetch to get a new option.) This is more about conceptual consistency completeness than new and useful addition, in that configured values and the feature they enable ought to be expressible and overridable from the command line options but we so far lacked a way to trigger the do not affect what gets fetched, only affect where they go locally feature, which is offered by the second way to use remote.*.fetch variable. I do not think we absolutely need it and that is why it is at the end as an optional addition. [jc: again, good suggestions I'll use when amending snipped] Thanks. -- 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
