{"thread":{"id":"8939","subject":"[PATCH v2] Make fetch-pack a builtin with an internal API","startedAt":"2007-07-09T05:10:16Z","lastAt":"2007-07-09T18:16:54Z","messageCount":10,"participants":["Daniel Barkalow","Junio C Hamano","Theodore Tso","Andy Parkins","Florian Weimer","René Scharfe"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"46824","messageId":"Pine.LNX.4.64.0707090104120.6977@iabervon.org","threadId":"8939","inReplyTo":null,"subject":"[PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-09T05:10:16Z","receivedAt":"2007-07-09T05:10:16Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"In addition to making fetch-pack a builtin, this allows it to be called \ndirectly from other built-in code without generating and parsing argument \nlists, which will be useful for builtin-fetch.\n\nIncidently, it makes git-fetch-pack not output lists of what it fetched \nwhen it fails.\n\nSigned-off-by: Daniel Barkalow <barkalow@iabervon.org>\n---\n Makefile                             |    1 +\n fetch-pack.c => builtin-fetch-pack.c |   92 ++++++++++++++++++++++++++--------\n builtin.h                            |    1 +\n fetch-pack.h                         |   16 ++++++\n git.c                                |    1 +\n 5 files changed, 89 insertions(+), 22 deletions(-)\n rename fetch-pack.c => builtin-fetch-pack.c (92%)\n create mode 100644 fetch-pack.h\n\ndiff --git a/Makefile b/Makefile\nindex 4ea5e45..da750f8 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -342,6 +342,7 @@ BUILTIN_OBJS = \\\n \tbuiltin-diff-files.o \\\n \tbuiltin-diff-index.o \\\n \tbuiltin-diff-tree.o \\\n+\tbuiltin-fetch-pack.o \\\n \tbuiltin-fetch--tool.o \\\n \tbuiltin-fmt-merge-msg.o \\\n \tbuiltin-for-each-ref.o \\\ndiff --git a/fetch-pack.c b/builtin-fetch-pack.c\nsimilarity index 92%\nrename from fetch-pack.c\nrename to builtin-fetch-pack.c\nindex 9c81305..27daa33 100644\n--- a/fetch-pack.c\n+++ b/builtin-fetch-pack.c\n@@ -6,6 +6,7 @@\n #include \"exec_cmd.h\"\n #include \"pack.h\"\n #include \"sideband.h\"\n+#include \"fetch-pack.h\"\n \n static int keep_pack;\n static int transfer_unpack_limit = -1;\n@@ -573,7 +574,7 @@ static int get_pack(int xd[2])\n \tdie(\"%s died of unnatural causes %d\", argv[0], status);\n }\n \n-static int fetch_pack(int fd[2], int nr_match, char **match)\n+static struct ref *do_fetch_pack(int fd[2], int nr_match, char **match)\n {\n \tstruct ref *ref;\n \tunsigned char sha1[20];\n@@ -615,12 +616,7 @@ static int fetch_pack(int fd[2], int nr_match, char **match)\n \t\tdie(\"git-fetch-pack: fetch failed.\");\n \n  all_done:\n-\twhile (ref) {\n-\t\tprintf(\"%s %s\\n\",\n-\t\t       sha1_to_hex(ref->old_sha1), ref->name);\n-\t\tref = ref->next;\n-\t}\n-\treturn 0;\n+\treturn ref;\n }\n \n static int remove_duplicates(int nr_heads, char **heads)\n@@ -663,15 +659,36 @@ static int fetch_pack_config(const char *var, const char *value)\n \n static struct lock_file lock;\n \n-int main(int argc, char **argv)\n+void setup_fetch_pack(const char *_uploadpack,\n+\t\t      int _quiet,\n+\t\t      int _keep_pack,\n+\t\t      int _unpacklimit,\n+\t\t      int _use_thin_pack,\n+\t\t      int _fetch_all,\n+\t\t      int _verbose,\n+\t\t      int _depth,\n+\t\t      int _no_progress)\n+{\n+\tuploadpack = _uploadpack;\n+\tquiet = _quiet;\n+\tkeep_pack = _keep_pack;\n+\tif (_unpacklimit >= 0)\n+\t\tunpack_limit = _unpacklimit;\n+\tif (keep_pack)\n+\t\tunpack_limit = 0;\n+\tuse_thin_pack = _use_thin_pack;\n+\tfetch_all = _fetch_all;\n+\tverbose = _verbose;\n+\tdepth = _depth;\n+\tno_progress = _no_progress;\n+}\n+\n+int cmd_fetch_pack(int argc, const char **argv, const char *prefix)\n {\n \tint i, ret, nr_heads;\n+\tstruct ref *ref;\n \tchar *dest = NULL, **heads;\n-\tint fd[2];\n-\tpid_t pid;\n-\tstruct stat st;\n \n-\tsetup_git_directory();\n \tgit_config(fetch_pack_config);\n \n \tif (0 <= transfer_unpack_limit)\n@@ -682,7 +699,7 @@ int main(int argc, char **argv)\n \tnr_heads = 0;\n \theads = NULL;\n \tfor (i = 1; i < argc; i++) {\n-\t\tchar *arg = argv[i];\n+\t\tconst char *arg = argv[i];\n \n \t\tif (*arg == '-') {\n \t\t\tif (!prefixcmp(arg, \"--upload-pack=\")) {\n@@ -716,8 +733,6 @@ int main(int argc, char **argv)\n \t\t\t}\n \t\t\tif (!prefixcmp(arg, \"--depth=\")) {\n \t\t\t\tdepth = strtol(arg + 8, NULL, 0);\n-\t\t\t\tif (stat(git_path(\"shallow\"), &st))\n-\t\t\t\t\tst.st_mtime = 0;\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!strcmp(\"--no-progress\", arg)) {\n@@ -726,22 +741,52 @@ int main(int argc, char **argv)\n \t\t\t}\n \t\t\tusage(fetch_pack_usage);\n \t\t}\n-\t\tdest = arg;\n-\t\theads = argv + i + 1;\n+\t\tdest = (char *)arg;\n+\t\theads = (char **)(argv + i + 1);\n \t\tnr_heads = argc - i - 1;\n \t\tbreak;\n \t}\n \tif (!dest)\n \t\tusage(fetch_pack_usage);\n-\tpid = git_connect(fd, dest, uploadpack, verbose ? CONNECT_VERBOSE : 0);\n+\n+\tref = fetch_pack(dest, nr_heads, heads);\n+\n+\tret = !ref;\n+\n+\twhile (ref) {\n+\t\tprintf(\"%s %s\\n\",\n+\t\t       sha1_to_hex(ref->old_sha1), ref->name);\n+\t\tref = ref->next;\n+\t}\n+\n+\treturn ret;\n+}\n+\n+struct ref *fetch_pack(const char *dest, int nr_heads, char **heads)\n+{\n+\tint i, ret;\n+\tint fd[2];\n+\tpid_t pid;\n+\tstruct ref *ref;\n+\tstruct stat st;\n+\n+\tif (depth > 0) {\n+\t\tif (stat(git_path(\"shallow\"), &st))\n+\t\t\tst.st_mtime = 0;\n+\t}\n+\n+\tprintf(\"connect to %s\\n\", dest);\n+\n+\tpid = git_connect(fd, (char *)dest, uploadpack,\n+                          verbose ? CONNECT_VERBOSE : 0);\n \tif (pid < 0)\n-\t\treturn 1;\n+\t\treturn NULL;\n \tif (heads && nr_heads)\n \t\tnr_heads = remove_duplicates(nr_heads, heads);\n-\tret = fetch_pack(fd, nr_heads, heads);\n+\tref = do_fetch_pack(fd, nr_heads, heads);\n \tclose(fd[0]);\n \tclose(fd[1]);\n-\tret |= finish_connect(pid);\n+\tret = finish_connect(pid);\n \n \tif (!ret && nr_heads) {\n \t\t/* If the heads to pull were given, we should have\n@@ -785,5 +830,8 @@ int main(int argc, char **argv)\n \t\t}\n \t}\n \n-\treturn !!ret;\n+\tif (ret)\n+\t\tref = NULL;\n+\n+\treturn ref;\n }\ndiff --git a/builtin.h b/builtin.h\nindex 661a92f..8fa38d4 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -31,6 +31,7 @@ extern int cmd_diff_files(int argc, const char **argv, const char *prefix);\n extern int cmd_diff_index(int argc, const char **argv, const char *prefix);\n extern int cmd_diff(int argc, const char **argv, const char *prefix);\n extern int cmd_diff_tree(int argc, const char **argv, const char *prefix);\n+extern int cmd_fetch_pack(int argc, const char **argv, const char *prefix);\n extern int cmd_fetch__tool(int argc, const char **argv, const char *prefix);\n extern int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix);\n extern int cmd_for_each_ref(int argc, const char **argv, const char *prefix);\ndiff --git a/fetch-pack.h b/fetch-pack.h\nnew file mode 100644\nindex 0000000..2bd05a8\n--- /dev/null\n+++ b/fetch-pack.h\n@@ -0,0 +1,16 @@\n+#ifndef FETCH_PACK_API\n+#define FETCH_PACK_API\n+\n+void setup_fetch_pack(const char *_uploadpack,\n+\t\t      int _quiet,\n+\t\t      int _keep_pack,\n+\t\t      int _unpacklimit,\n+\t\t      int _use_thin_pack,\n+\t\t      int _fetch_all,\n+\t\t      int _verbose,\n+\t\t      int _depth,\n+\t\t      int _no_progress);\n+\n+struct ref *fetch_pack(const char *dest, int nr_heads, char **heads);\n+\n+#endif\ndiff --git a/git.c b/git.c\nindex b949cbb..df45161 100644\n--- a/git.c\n+++ b/git.c\n@@ -307,6 +307,7 @@ static void handle_internal_command(int argc, const char **argv)\n \t\t{ \"diff-files\", cmd_diff_files },\n \t\t{ \"diff-index\", cmd_diff_index, RUN_SETUP },\n \t\t{ \"diff-tree\", cmd_diff_tree, RUN_SETUP },\n+\t\t{ \"fetch-pack\", cmd_fetch_pack, RUN_SETUP },\n \t\t{ \"fetch--tool\", cmd_fetch__tool, RUN_SETUP },\n \t\t{ \"fmt-merge-msg\", cmd_fmt_merge_msg, RUN_SETUP },\n \t\t{ \"for-each-ref\", cmd_for_each_ref, RUN_SETUP },\n-- \n1.5.2.2.1399.g097d5-dirty\n"},{"id":"46828","messageId":"7vwsxaw2xu.fsf@assigned-by-dhcp.cox.net","threadId":"8939","inReplyTo":"Pine.LNX.4.64.0707090104120.6977@iabervon.org","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-09T05:39:41Z","receivedAt":"2007-07-09T05:39:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Are _identifiers with leading underscore Kosher thing to do, I\nwonder...  We do have ones with trailing ones (mostly qsort\nfunctions) and I think they are done that way for the sake of\nstandards conformance.\n\nGone is a \"#if 0/#endif\" which is good.\n\ndiff --git a/fetch-pack.h b/fetch-pack.h\nnew file mode 100644\nindex 0000000..2bd05a8\n--- /dev/null\n+++ b/fetch-pack.h\n@@ -0,0 +1,16 @@\n+#ifndef FETCH_PACK_API\n\nWe seem to say \"#ifndef FETCH_PACK_H\" in such a case, though.\nNobody seems to call setup_fetch_pack() yet.  How complete is\nthis patch meant to be?\n\nThe program is somehow much more pleasant to follow, even though\nthere is no fundamental change anywhere.\n"},{"id":"46835","messageId":"Pine.LNX.4.64.0707090142130.6977@iabervon.org","threadId":"8939","inReplyTo":"7vwsxaw2xu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-09T06:37:34Z","receivedAt":"2007-07-09T06:37:34Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 8 Jul 2007, Junio C Hamano wrote:\n\n> Are _identifiers with leading underscore Kosher thing to do, I\n> wonder...  We do have ones with trailing ones (mostly qsort\n> functions) and I think they are done that way for the sake of\n> standards conformance.\n\nI'm not sure; I inherited that bit of code from Julian. Do we have a \nstandard idiom for a function that sets a bunch of static variables?\n\n> diff --git a/fetch-pack.h b/fetch-pack.h\n> new file mode 100644\n> index 0000000..2bd05a8\n> --- /dev/null\n> +++ b/fetch-pack.h\n> @@ -0,0 +1,16 @@\n> +#ifndef FETCH_PACK_API\n> \n> We seem to say \"#ifndef FETCH_PACK_H\" in such a case, though.\n\nI was trying to convey that this is the C API to call fetch-pack directly, \nrather than something used by the builtin, or by the wrapper for calling \nthe builtin. But the inclusion guard is probably not going to be noticed \nanyway, and I don't think it's worth making the header filename verbose.\n\n> Nobody seems to call setup_fetch_pack() yet.  How complete is\n> this patch meant to be?\n\nIt's part of a series that leads up to making fetch a builtin. I'm trying \nto get in bits that are bounded by logical APIs. The roadmap here is that \ntransport.{c,h} from one of my other patches will get a function to fetch \na set of refs, and it will (for a suitable URL format) call \nsetup_fetch_pack() with the appropriate options and then call \nfetch_pack(). builtin-fetch will use this function to actually get objects \nonce it has determined which ones it should get.\n\nI think I've now got the whole series to a point where everything's \nsubmittable, if you'd like to see the whole thing. It's actually composed \nof 6 initial independant sub-series (mostly single patches) of which I've \nsubmitted 4 (three today and the one that modularizes the commit-walker \ninfrastructure and removes the obsolete ones), and a final series of 3 \nthat implements fetch on top of the rest. How should I number this?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"46856","messageId":"20070709115029.GD16032@thunk.org","threadId":"8939","inReplyTo":"7vwsxaw2xu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-09T11:50:29Z","receivedAt":"2007-07-09T11:50:29Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Jul 08, 2007 at 10:39:41PM -0700, Junio C Hamano wrote:\n> Are _identifiers with leading underscore Kosher thing to do, I\n> wonder...  We do have ones with trailing ones (mostly qsort\n> functions) and I think they are done that way for the sake of\n> standards conformance.\n\n_[a-z]* is kosher for file scopes or function scoping:\n\n\thttp://c-faq.com/decl/namespace.html\n\nSome Projects' coding styles prohibit use of _[a-z]* altogether, as\n_[_A-Z]* is reserved for C libraries and system header files, and it's\nsimpler just to ban all identifiers begining with an underscore just\non general princinpals.  It's not strictly speaking necessary, however.\n\n\t       \t\t     \t    - Ted\n\nP.S.  Note that the Linux kernel does not worry about such rules; in\nparticular, _[a-z]* is very commonly used at the global scope level,\nwithout any problems.  It doesn't have to be as portable as git\nprobably needs to be, however.\n"},{"id":"46862","messageId":"200707091416.39949.andyparkins@gmail.com","threadId":"8939","inReplyTo":"20070709115029.GD16032@thunk.org","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-07-09T13:16:35Z","receivedAt":"2007-07-09T13:16:35Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 July 09, Theodore Tso wrote:\n> On Sun, Jul 08, 2007 at 10:39:41PM -0700, Junio C Hamano wrote:\n> > Are _identifiers with leading underscore Kosher thing to do, I\n> > wonder...  We do have ones with trailing ones (mostly qsort\n> > functions) and I think they are done that way for the sake of\n> > standards conformance.\n>\n> _[a-z]* is kosher for file scopes or function scoping:\n\nPerhaps I'm reading it wrong but:\n\n\"All identifiers beginning with an underscore are reserved for ordinary \nidentifiers (functions, variables, typedefs, enumeration constants) with file \nscope.\"\n\nDoesn't agree with what you've said.  I think that you _can_ use _[a-z]* for \nlabels or structure members - however, not within file or function scope.\n\nHowever, the rule of thumb I've always used is \"don't start identifiers with \nunderscore\".  I can't think of a situation that would mean you have to use an \nunderscore to start an identifier - so why get into detailed worries about \nwhere it's allowed and where it isn't.  Just don't use it.  The document you \nlinked to gives exactly this advice:\n\n\"Don't give anything a name with a leading underscore.\"\n\n> P.S.  Note that the Linux kernel does not worry about such rules; in\n> particular, _[a-z]* is very commonly used at the global scope level,\n> without any problems.  It doesn't have to be as portable as git\n> probably needs to be, however.\n\nThe kernel doesn't use any standard library so there is nothing for it to \nconflict with.  I don't think it's that the kernel doesn't worry about those \nrules, it's that those rules don't apply (just as they don't for glibc).  The \nunderscore rules aren't a limitation of the language, they are a limitation \nimposed by the standard library.  \n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"46868","messageId":"20070709144030.GE16032@thunk.org","threadId":"8939","inReplyTo":"200707091416.39949.andyparkins@gmail.com","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-09T14:40:30Z","receivedAt":"2007-07-09T14:40:30Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jul 09, 2007 at 02:16:35PM +0100, Andy Parkins wrote:\n> On Monday 2007 July 09, Theodore Tso wrote:\n> > On Sun, Jul 08, 2007 at 10:39:41PM -0700, Junio C Hamano wrote:\n> > > Are _identifiers with leading underscore Kosher thing to do, I\n> > > wonder...  We do have ones with trailing ones (mostly qsort\n> > > functions) and I think they are done that way for the sake of\n> > > standards conformance.\n> >\n> > _[a-z]* is kosher for file scopes or function scoping:\n> \n> Perhaps I'm reading it wrong but:\n> \n> \"All identifiers beginning with an underscore are reserved for ordinary \n> identifiers (functions, variables, typedefs, enumeration constants) with file \n                                                                      ^^^^^^^^^\n> scope.\"\n  ^^^^^^\n> \n> Doesn't agree with what you've said.  I think that you _can_ use _[a-z]* for \n> labels or structure members - however, not within file or function scope.\n\nI think the above does agree with what I said.  It says that you can\nuse functions, variables, typdefs, enumeration constants (not just\nlabels or structure members) WITH FILE SCOPE.  I.e., so long as it\ndoesn't leak across a .o linkage.  So one .o file can use a static\n_my_strdup, and another .o file can use a static _my_strdup, and they\ndon't have to worry about multiply defined function conflicts, since\nthey are static functions with file or smaller scoping.\n\nAnd if it's safe to use a file-level static scoping, then obviously it\nwould be safe to use a function-level static scoping.\n\n> However, the rule of thumb I've always used is \"don't start identifiers with \n> underscore\".  I can't think of a situation that would mean you have to use an \n> underscore to start an identifier - so why get into detailed worries about \n> where it's allowed and where it isn't.  Just don't use it.  The document you \n> linked to gives exactly this advice:\n\nYep, this is the safer thing to do if you don't want to remember the\nmore complicated rule.  But it's not *necessary*; no system library\nwill use a single underscore followed by a lower-case letter, since\nthat's reserved for programs for local file-level scoping.  A system\nlibrary will use for its private function identifiers that begin\neither a double underscore, or a underscore followed by an uppercase\nlatter.\n\nRegards,\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"46871","messageId":"874pkdlij7.fsf@mid.deneb.enyo.de","threadId":"8939","inReplyTo":"20070709144030.GE16032@thunk.org","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-07-09T15:10:36Z","receivedAt":"2007-07-09T15:10:36Z","isPatch":true,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Theodore Tso:\n\n> On Mon, Jul 09, 2007 at 02:16:35PM +0100, Andy Parkins wrote:\n\n>> Perhaps I'm reading it wrong but:\n>> \n>> \"All identifiers beginning with an underscore are reserved for ordinary \n>> identifiers (functions, variables, typedefs, enumeration constants) with file \n>                                                                       ^^^^^^^^^\n>> scope.\"\n>   ^^^^^^\n>> \n>> Doesn't agree with what you've said.  I think that you _can_ use _[a-z]* for \n>> labels or structure members - however, not within file or function scope.\n>\n> I think the above does agree with what I said.  It says that you can\n> use functions, variables, typdefs, enumeration constants (not just\n> labels or structure members) WITH FILE SCOPE.\n\nNo, they are are reserved.\n\n> I.e., so long as it doesn't leak across a .o linkage.  So one .o\n> file can use a static _my_strdup, and another .o file can use a\n> static _my_strdup, and they don't have to worry about multiply\n> defined function conflicts, since they are static functions with\n> file or smaller scoping.\n\nThis is not sufficient because the implementation might have a\n*typedef* for _my_strdup in any header file, and neither translation\nunit would compile.  Or they could have been declared with a different\nprototype.\n"},{"id":"46873","messageId":"200707091628.14377.andyparkins@gmail.com","threadId":"8939","inReplyTo":"20070709144030.GE16032@thunk.org","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-07-09T15:28:12Z","receivedAt":"2007-07-09T15:28:12Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 July 09, Theodore Tso wrote:\n> > \"All identifiers beginning with an underscore are reserved for ordinary\n> > identifiers (functions, variables, typedefs, enumeration constants) with\n> > file\n> > scope.\"\n\n> I think the above does agree with what I said.  It says that you can\n> use functions, variables, typdefs, enumeration constants (not just\n> labels or structure members) WITH FILE SCOPE.  I.e., so long as it\n> doesn't leak across a .o linkage.  So one .o file can use a static\n\nI'm reading it as meaning they are reserved at file scope; not that you can \nuse them at file scope.\n\n> _my_strdup, and another .o file can use a static _my_strdup, and they\n> don't have to worry about multiply defined function conflicts, since\n> they are static functions with file or smaller scoping.\n\nErm, but we're not talking about your own .o files we're talking about \nconflicting with the library; what you say would be true for any identifier.  \nWe have no way of guaranteeing that _my_strdup() isn't defined by one of the \nstandard library headers that have been included.  The standard header is \nentitled to use underscore identifiers because they have been reserved at \nfile scope.\n\nReading a little further into the FAQ you posted, I found the following in the \nlist of exceptions:\n\n\"You may use identifiers consisting of an underscore followed by a digit or \nlower case letter for labels and structure/union members.\" \nand\n\"You may use identifiers consisting of an underscore followed by a digit or \nlower case letter at function, block, or prototype scope.\"\n\nI'm more sure now - you can't use underscore identifiers at file scope.\n\nRegardless, we're just splitting hairs now.  We seem to both agree that it's \neasiest just to outright not use underscore-prefixed identifiers; so I'm \nhappy. :-)\n\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"46881","messageId":"469278B3.40905@lsrfire.ath.cx","threadId":"8939","inReplyTo":"Pine.LNX.4.64.0707090142130.6977@iabervon.org","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-07-09T18:04:35Z","receivedAt":"2007-07-09T18:04:35Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Daniel Barkalow schrieb:\n> On Sun, 8 Jul 2007, Junio C Hamano wrote:\n> \n>> Are _identifiers with leading underscore Kosher thing to do, I\n>> wonder...  We do have ones with trailing ones (mostly qsort\n>> functions) and I think they are done that way for the sake of\n>> standards conformance.\n> \n> I'm not sure; I inherited that bit of code from Julian. Do we have a \n> standard idiom for a function that sets a bunch of static variables?\n\nYou could put all flags and settings into a struct fetch_pack_args.\n\nYou could then go one step further by exporting the struct definition\nand letting the internal interface take a pointer to such a struct,\nthereby getting rid of static variables and their setup routine.\n\nRené\n"},{"id":"46882","messageId":"Pine.LNX.4.64.0707091408190.6977@iabervon.org","threadId":"8939","inReplyTo":"469278B3.40905@lsrfire.ath.cx","subject":"Re: [PATCH v2] Make fetch-pack a builtin with an internal API","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-09T18:16:54Z","receivedAt":"2007-07-09T18:16:54Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 9 Jul 2007, René Scharfe wrote:\n\n> Daniel Barkalow schrieb:\n> > On Sun, 8 Jul 2007, Junio C Hamano wrote:\n> > \n> >> Are _identifiers with leading underscore Kosher thing to do, I\n> >> wonder...  We do have ones with trailing ones (mostly qsort\n> >> functions) and I think they are done that way for the sake of\n> >> standards conformance.\n> > \n> > I'm not sure; I inherited that bit of code from Julian. Do we have a \n> > standard idiom for a function that sets a bunch of static variables?\n> \n> You could put all flags and settings into a struct fetch_pack_args.\n> \n> You could then go one step further by exporting the struct definition\n> and letting the internal interface take a pointer to such a struct,\n> thereby getting rid of static variables and their setup routine.\n\nThis code is going to get an extensive refactor at some point (I'd like to \nget to the point where git-fetch uses only a single connection), but \nthat's a much bigger patch, and I want to get builtin-fetch done with \nminimal changes to other code; passing configuration through to everywhere \nthat uses it would add a lot of noise at this stage.\n\nPassing a pointer to a struct instead of a pile of ints in hopefully the \nright order is probably a worthwhile improvement to reviewability, though, \nso I'll try that much this evening.\n\n\t-Daniel\n*This .sig left intentionally blank*"}]}