I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Hi,
git-fetch builtinification (commit v1.5.3.2-93-gb888d61) apparently dropped -n option (alias to --no-tags) documented in Documentation/fetch-options.txt
Either builtin-fetch.c or Documentation/fetch-options.txt should be adjusted to sync the code with its docs.
Original bug report:
https://bugzilla.altlinux.org/show_bug.cgi?id=14870
Signature · 1 line
ldv
Quoted 6 lines · Dmitry V. Levin
Hi,
git-fetch builtinification (commit v1.5.3.2-93-gb888d61) apparently dropped -n option (alias to --no-tags) documented in
Documentation/fetch-options.txt
Quoted 6 lines
Either
builtin-fetch.corDocumentation/fetch-options.txtshould be adjusted to sync the code with its docs.Original bug report:
https://bugzilla.altlinux.org/show_bug.cgi?id=14870
I have a (very) vague memory that git-fetch.sh had to iterate over tags one by one, making tag-heavy projects excruciatingly slow to fetch from with the shellscript version. Some pathological case with 2700 tags was presented where a fetch took nearly an hour, iirc. AFAIR, the builtinification (or was it a protocol extension?) reduced that time to something around 10 seconds for the pathological case.
Does anyone else have a sharper memory of what caused the -n option to be dropped?
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Hi,
Quoted 12 lines · Andreas Ericsson
Quoted 9 lines · Dmitry V. Levin
git-fetch builtinification (commit v1.5.3.2-93-gb888d61) apparently dropped -n option (alias to --no-tags) documented in
Documentation/fetch-options.txtEither
builtin-fetch.corDocumentation/fetch-options.txtshould be adjusted to sync the code with its docs.Original bug report:
https://bugzilla.altlinux.org/show_bug.cgi?id=14870
Quoted 6 lines
I have a (very) vague memory that
git-fetch.shhad to iterate over tags one by one, making tag-heavy projects excruciatingly slow to fetch from with the shellscript version. Some pathological case with 2700 tags was presented where a fetch took nearly an hour, iirc. AFAIR, the builtinification (or was it a protocol extension?) reduced that time to something around 10 seconds for the pathological case.
AFAIR this was helped by the fetch--tool helper, even at the time of non-builtin fetch.
Quoted 2 lines
Does anyone else have a sharper memory of what caused the -n option to be dropped?
AFAICT this was done because of the parsopt'ification. But I forgot the details.
Hth,
Dscho
Quoted 10 lines · Johannes Schindelin
Hi,
Quoted 6 lines · Andreas Ericsson
Quoted 4 lines · Dmitry V. Levin
git-fetch builtinification (commit v1.5.3.2-93-gb888d61) apparently dropped -n option (alias to --no-tags) documented in
Documentation/fetch-options.txtEither
builtin-fetch.corDocumentation/fetch-options.txtshould be adjusted to sync the code with its docs.
Quoted 9 lines
Quoted 2 lines
Quoted 1 line
Original bug report: https://bugzilla.altlinux.org/show_bug.cgi?id=14870
I have a (very) vague memory that
git-fetch.shhad to iterate over tags one by one, making tag-heavy projects excruciatingly slow to fetch from with the shellscript version. Some pathological case with 2700 tags was presented where a fetch took nearly an hour, iirc. AFAIR, the builtinification (or was it a protocol extension?) reduced that time to something around 10 seconds for the pathological case.AFAIR this was helped by the fetch--tool helper, even at the time of non-builtin fetch.
Quoted 1 line
Does anyone else have a sharper memory of what caused the -n option to be dropped?
AFAICT this was done because of the parsopt'ification. But I forgot the details.
I had a look at the code. It seems the new way of specifying -n is to say --no-tags or -t 0, or --tags=0 (although I'm not well-versed enough in the parseopt thing to be sure). I have no time now, but I'll take a stab at adding the -n option back tomorrow if nobody beats me to it.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Hi,
Quoted 29 lines · Andreas Ericsson
Quoted 27 lines · Johannes Schindelin
Quoted 11 lines · Andreas Ericsson
Quoted 9 lines · Dmitry V. Levin
git-fetch builtinification (commit v1.5.3.2-93-gb888d61) apparently dropped -n option (alias to --no-tags) documented in
Documentation/fetch-options.txtEither
builtin-fetch.corDocumentation/fetch-options.txtshould be adjusted to sync the code with its docs.Original bug report:
https://bugzilla.altlinux.org/show_bug.cgi?id=14870Quoted 7 lines
I have a (very) vague memory that
git-fetch.shhad to iterate over tags one by one, making tag-heavy projects excruciatingly slow to fetch from with the shellscript version. Some pathological case with 2700 tags was presented where a fetch took nearly an hour, iirc. AFAIR, the builtinification (or was it a protocol extension?) reduced that time to something around 10 seconds for the pathological case.AFAIR this was helped by the fetch--tool helper, even at the time of non-builtin fetch.
Quoted 2 lines
Does anyone else have a sharper memory of what caused the -n option to be dropped?
Quoted 8 lines
Quoted 3 lines
AFAICT this was done because of the parsopt'ification. But I forgot the details.
I had a look at the code. It seems the new way of specifying -n is to say --no-tags or -t 0, or --tags=0 (although I'm not well-versed enough in the parseopt thing to be sure). I have no time now, but I'll take a stab at adding the -n option back tomorrow if nobody beats me to it.
Maybe like this (completely untested, that will be your task tomorrow):
builtin-fetch.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
builtin-fetch.c +2 -0
@@ -40,6 +40,8 @@ static struct option builtin_fetch_options[] = { "force overwrite of local branch"),OPT_SET_INT ('t' ,"tags" , &tags,"fetch all tags and associated objects" ,TAGS_SET ), +OPT_SET_INT ('n' ,NULL , &tags, +"do not fetch all tags (--no-tags)" ,TAGS_UNSET ),OPT_BOOLEAN ('k' ,"keep" , &keep,"keep downloaded pack" ),OPT_BOOLEAN ('u' ,"update-head-ok" , &update_head_ok, "allow updating of HEAD ref"),
Quoted 16 lines · Johannes Schindelin
Hi,
Quoted 12 lines · Andreas Ericsson
Quoted 10 lines · Johannes Schindelin
Quoted 8 lines · Andreas Ericsson
Quoted 5 lines · Dmitry V. Levin
git-fetch builtinification (commit v1.5.3.2-93-gb888d61) apparently dropped -n option (alias to --no-tags) documented in
Documentation/fetch-options.txtEither
builtin-fetch.corDocumentation/fetch-options.txtshould be adjusted to sync the code with its docs.Original bug report: https://bugzilla.altlinux.org/show_bug.cgi?id=14870
I have a (very) vague memory that
git-fetch.shhad to iterate over tags one by one, making tag-heavy projects excruciatingly slow to fetch from with the shellscript version. Some pathological case with 2700 tags was presented where a fetch took nearly an hour, iirc. AFAIR, the builtinification (or was it a protocol extension?) reduced that time to something around 10 seconds for the pathological case.
Quoted 9 lines
Quoted 6 lines
Quoted 5 lines
AFAIR this was helped by the fetch--tool helper, even at the time of non-builtin fetch.
Quoted 1 line
Does anyone else have a sharper memory of what caused the -n option to be dropped?
AFAICT this was done because of the parsopt'ification. But I forgot the details.
I had a look at the code. It seems the new way of specifying -n is to say --no-tags or -t 0, or --tags=0 (although I'm not well-versed enough in the parseopt thing to be sure). I have no time now, but I'll take a stab at adding the -n option back tomorrow if nobody beats me to it.
Maybe like this (completely untested, that will be your task tomorrow):
Looks like how I thought it should be. Test passed fine, both real and automated. Proper patch incoming in a minute.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
PATCH 1/1 git fetch: Take '-n' to mean '--no-tags'
From: Johannes Schindelin <[email protected]>
Prior to commit 83201998730ac5f0b95ac832f3b727da26ab0129, we understood '-n' as a short option to mean "don't fetch tags from the remote". This patch reinstates behaviour similar, but not identical to the pre commit 832019987 times.
Back then, -n always overrode --tags, so if both --tags and -n was given on command-line, no tags were fetched regardless of argument ordering. Now we use a "last entry wins" strategy, so '-n --tags' means "fetch tags".
Since it's patently absurd to say both --tags and --no-tags this shouldn't matter in practice.
---
Quoted 8 lines · Andreas Ericsson
Quoted 3 lines · Johannes Schindelin
Maybe like this (completely untested, that will be your task tomorrow):
Looks like how I thought it should be. Test passed fine, both real and automated. Proper patch incoming in a minute.
And here it is.
builtin-fetch.c +0 -0
@@ -40,6 +40,8 @@ static struct option builtin_fetch_options[] = {
"force overwrite of local branch"),
OPT_SET_INT('t', "tags", &tags,
"fetch all tags and associated objects", TAGS_SET),
+ OPT_SET_INT('n', NULL, &tags,
+ "do not fetch all tags (--no-tags)", TAGS_UNSET),
OPT_BOOLEAN('k', "keep", &keep, "keep downloaded pack"), OPT_BOOLEAN('u', "update-head-ok", &update_head_ok,
"allow updating of HEAD ref"),
Signature · 6 lines
1.5.4.4.532.ga6828.dirty -- Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Re: [PATCH] git fetch: Take '-n' to mean '--no-tags'
Very well done. Thanks.