threads / discuss / 12645
Subject: I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Dmitry V. LevinHi,
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
-- ldv
Andreas EricssonRe: I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Dmitry V. Levin wrote:
> 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 >
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?
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Johannes SchindelinRe: I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Hi,
On Wed, 12 Mar 2008, Andreas Ericsson wrote:
> Dmitry V. Levin wrote: > > > 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 > > 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.
AFAIR this was helped by the fetch--tool helper, even at the time of non-builtin fetch.
> 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
Andreas EricssonRe: I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Johannes Schindelin wrote:
> Hi, > > On Wed, 12 Mar 2008, Andreas Ericsson wrote: > >> Dmitry V. Levin wrote: >> >>> 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 >> 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. > > AFAIR this was helped by the fetch--tool helper, even at the time of > non-builtin fetch. > >> 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.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Johannes SchindelinRe: I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Hi,
On Wed, 12 Mar 2008, Andreas Ericsson wrote:
> Johannes Schindelin wrote: > > > On Wed, 12 Mar 2008, Andreas Ericsson wrote: > > > > > Dmitry V. Levin wrote: > > > > > > > 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 > > > 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. > > > > AFAIR this was helped by the fetch--tool helper, even at the time of > > non-builtin fetch. > > > > > 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):
builtin-fetch.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c index 5196688..c406298 100644 --- a/builtin-fetch.c +++ b/builtin-fetch.c @@ -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"),
Andreas EricssonRe: I: git-fetch: -n option disappeared but git-fetch(1) still describe it
Johannes Schindelin wrote:
> Hi, > > On Wed, 12 Mar 2008, Andreas Ericsson wrote: > >> Johannes Schindelin wrote: >> >>> On Wed, 12 Mar 2008, Andreas Ericsson wrote: >>> >>>> Dmitry V. Levin wrote: >>>> >>>>> 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 >>>> 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. >>> AFAIR this was helped by the fetch--tool helper, even at the time of >>> non-builtin fetch. >>> >>>> 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.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Andreas Ericsson[PATCH] git fetch: Take '-n' to mean '--no-tags'
From: Johannes Schindelin <johannes.schindelin@gmx.de>
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.
Spotted-by: Artem Zolochevskiy <azol@altlinux.org> Reported-by: Dmitry V. Levin <ldv@altlinux.org> Tested-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> ---
Andreas Ericsson wrote:
> Johannes Schindelin wrote: >> >> 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.
diff --git a/builtin-fetch.c b/builtin-fetch.c index 55f611e..b2b9935 100644 --- a/builtin-fetch.c +++ b/builtin-fetch.c @@ -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"),
-- 1.5.4.4.532.ga6828.dirty -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
