{"thread":{"id":"8671","subject":"[PATCH] Introduce git version --list-features for porcelain use","startedAt":"2007-06-21T04:59:03Z","lastAt":"2007-06-22T14:03:24Z","messageCount":16,"participants":["Shawn O. Pearce","Junio C Hamano","Johannes Schindelin","Nicolas Pitre","Josef Weidendorfer","Catalin Marinas"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"45465","messageId":"20070621045903.GA14047@spearce.org","threadId":"8671","inReplyTo":null,"subject":"[PATCH] Introduce git version --list-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-21T04:59:03Z","receivedAt":"2007-06-21T04:59:03Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"As a porcelain author I'm finding it difficult to keep track of\nwhat features I can use in git-gui. Newer versions of Git have\nnewer capabilities but they don't always immediately get newer\nversion numbers that I can easily test for.\n\nThis is a simple plumbing option that lets a porcelain ask the\nplumbing for its capabilities, at which point the porcelain can\nwork around anything missing, or recommend to the user that they\nupgrade their plumbing layer.\n\nSigned-off-by: Shawn O. Pearce \n---\n\n Because 'maint' does not support `git-blame -w` I can't apply your\n recent (and insanely good idea) 'git-gui: use \"blame -w -C -C\" for\n \"where did it come from, originally?\"' without something like the\n following, so I know that `git blame -w -C -C` will be accepted\n by the underlying plumbing. ;-)\n\n help.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++-\n t/t0000-basic.sh | 16 +++++++++++\n 2 files changed, 91 insertions(+), 2 deletions(-)\n\ndiff --git a/help.c b/help.c\nindex 1cd33ec..9f24a0f 100644\n--- a/help.c\n+++ b/help.c\n@@ -9,6 +9,11 @@\n #include \"common-cmds.h\"\n #include \n \n+static const char *supported_features[] = {\n+\t\"blame-ignore-whitespace\",\n+\t\"list-features\",\n+};\n+\n /* most GUI terminals set COLUMNS (although some don't export it) */\n static int term_columns(void)\n {\n@@ -190,10 +195,78 @@ void help_unknown_cmd(const char *cmd)\n \texit(1);\n }\n \n+static int is_feature_name_sane(const char *a)\n+{\n+\tif (!*a || *a == '-')\n+\t\treturn 0;\n+\tfor (; *a; a++) {\n+\t\tif (! ((*a >= 'a' && *a <= 'z')\n+\t\t || (*a >= '0' && *a <= '9')\n+\t\t || *a == '-'))\n+\t\t\treturn 0;\n+\t}\n+\treturn 1;\n+}\n+\n+static int cmp_feature(const void *a_, const void *b_)\n+{\n+\tconst char *a = *((const char **)a_);\n+\tconst char *b = *((const char **)b_);\n+\treturn strcmp(a, b);\n+}\n+\n+static void list_features()\n+{\n+\tunsigned cnt = ARRAY_SIZE(supported_features);\n+\tunsigned i;\n+\n+\tqsort(supported_features, cnt,\n+\t\tsizeof(supported_features[0]), cmp_feature);\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tconst char *f = supported_features[i];\n+\t\tif (!is_feature_name_sane(f))\n+\t\t\tdie(\"feature name \\\"%s\\\" is bogus\", f);\n+\t\tprintf(\"%s\\n\", f);\n+\t}\n+}\n+\n+static int supports_feature(const char *the_feature)\n+{\n+\tunsigned cnt = ARRAY_SIZE(supported_features);\n+\tunsigned i;\n+\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tif (!strcmp(supported_features[i], the_feature))\n+\t\t\treturn 0;\n+\t}\n+\treturn 1;\n+}\n+\n+static const char version_usage[] =\n+\"git-version [(--list-features | --supports-feature=*)]\";\n+\n int cmd_version(int argc, const char **argv, const char *prefix)\n {\n-\tprintf(\"git version %s\\n\", git_version_string);\n-\treturn 0;\n+\tint i, ret = 0, list = 0, test = 0;\n+\n+\tfor (i = 1; i < argc; i++) {\n+\t\tconst char *arg = argv[i];\n+\t\tif (!strcmp(arg, \"--list-features\"))\n+\t\t\tlist = 1;\n+\t\telse if (!prefixcmp(arg, \"--supports-feature=\")) {\n+\t\t\ttest = 1;\n+\t\t\tret |= supports_feature(arg + 19);\n+\t\t} else\n+\t\t\tusage(version_usage);\n+\t}\n+\n+\tif (list && test)\n+\t\tdie(\"cannot use both --list-features and --supports-feature\");\n+\tif (list)\n+\t\tlist_features();\n+\tif (!list && !test)\n+\t\tprintf(\"git version %s\\n\", git_version_string);\n+\treturn ret;\n }\n \n int cmd_help(int argc, const char **argv, const char *prefix)\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 8bfe832..9fc5824 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -31,6 +31,22 @@ fi\n . ./test-lib.sh\n \n ################################################################\n+# git version\n+\n+test_expect_success \\\n+\t'git version is functional' \\\n+\t'git version'\n+test_expect_success \\\n+\t'git version --list-features' \\\n+\t'git version --list-features'\n+test_expect_success \\\n+\t'feature \"list-features\" is supported' \\\n+\t'git version --supports-feature=list-features'\n+test_expect_failure \\\n+\t'feature \"THISNEVERWILLBEAGITFEATURE\" is not supported' \\\n+\t'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'\n+\n+################################################################\n # git-init has been done in an empty repository.\n # make sure it is empty.\n \n-- \n1.5.2.2.1050.g51a8b\n"},{"id":"45467","messageId":"7v1wg55065.fsf@assigned-by-dhcp.pobox.com","threadId":"8671","inReplyTo":"20070621045903.GA14047@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-21T05:47:14Z","receivedAt":"2007-06-21T05:47:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> As a porcelain author I'm finding it difficult to keep track of\n> what features I can use in git-gui. Newer versions of Git have\n> newer capabilities but they don't always immediately get newer\n> version numbers that I can easily test for.\n\nTwo and half comments, and a discussion.\n\n> +static const char *supported_features[] = {\n> +\t\"blame-ignore-whitespace\",\n> +\t\"list-features\",\n> +};\n> +\n> /* most GUI terminals set COLUMNS (although some don't export it) */\n> static int term_columns(void)\n> {\n> @@ -190,10 +195,78 @@ void help_unknown_cmd(const char *cmd)\n> \texit(1);\n> }\n> \n> +static int is_feature_name_sane(const char *a)\n> +{\n> +\tif (!*a || *a == '-')\n> +\t\treturn 0;\n> +\tfor (; *a; a++) {\n> +\t\tif (! ((*a >= 'a' && *a <= 'z')\n> +\t\t || (*a >= '0' && *a <= '9')\n> +\t\t || *a == '-'))\n> +\t\t\treturn 0;\n> +\t}\n> +\treturn 1;\n> +}\n> +\n\n> +static int cmp_feature(const void *a_, const void *b_)\n> +{\n> +\tconst char *a = *((const char **)a_);\n> +\tconst char *b = *((const char **)b_);\n> +\treturn strcmp(a, b);\n> +}\n> +\n> +static void list_features()\n> +{\n> +\tunsigned cnt = ARRAY_SIZE(supported_features);\n> +\tunsigned i;\n> +\n> +\tqsort(supported_features, cnt,\n> +\t\tsizeof(supported_features[0]), cmp_feature);\n> ...\n> +}\n\nUnless we are talking about dynamically extensible feature list\n(eh, dll, anybody?), it might be easier to keep (1) the list\nsorted, and (2) free of insane feature name in\nsupported_features[] array at the source level. Then you can\nlose that is_feature_name_sane() function.\n\n> +static int supports_feature(const char *the_feature)\n> +{\n> +\tunsigned cnt = ARRAY_SIZE(supported_features);\n> +\tunsigned i;\n> +\n> +\tfor (i = 0; i < cnt; i++) {\n> +\t\tif (!strcmp(supported_features[i], the_feature))\n> +\t\t\treturn 0;\n> +\t}\n> +\treturn 1;\n> +}\n\nAnd you can perform a bsearch here. instead of linear.\n\n> +test_expect_failure \\\n> +\t'feature \"THISNEVERWILLBEAGITFEATURE\" is not supported' \\\n> +\t'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'\n\nI would expect that THISNEW... will get complaint saying \"That\nis not a valid feature name, as it has uppercase\", from a\nversion that has is_feature_name_sane() function.\n\nI suspect that this patch is meant for my 'maint' (and\n1.5.2.3). Or is it for my 'master'? What's your plan to handle\ntransition?\n\nFor example, if this appears on 1.5.2.3, then\nsupported_features[] should not have blame-ignore-whitespace,\nunless we are talking about cherry-picking, and I honestly do\nnot think \"blame -w\" deserves to go to the maintenance only\nseries. On the other hand, --list-features could go to 'maint'\nunder 'future prooofing' category, I guess.\n\nIf this is meant to be only for 1.5.3 and later, then you know\nthat \"blame -w\" is available as well, so the fact you can do\n\"git version --list-features\" alone tells you that you can use\n\"blame -w\", among other many things, such as \"diff -C -C\"\ninstead of --find-copies-harder.\n\nWhere does the above discussion lead us? It essentially means,\nin either case, \"blame-ignore-whitespace\" should not be in that\nsupported_features[] array.\n"},{"id":"45469","messageId":"20070621061045.GG8477@spearce.org","threadId":"8671","inReplyTo":"7v1wg55065.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-21T06:10:45Z","receivedAt":"2007-06-21T06:10:45Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Unless we are talking about dynamically extensible feature list\n> (eh, dll, anybody?), it might be easier to keep (1) the list\n> sorted, and (2) free of insane feature name in\n> supported_features[] array at the source level. Then you can\n> lose that is_feature_name_sane() function.\n\nYes, this is true. But I'm being overly defensive here. If the\nlist does get out of order we force it back in --list-features just\nto be consistent in output, and t0000 will fail if any item in the\nlist is insane.\n\nIf you want to be less defensive, OK, it would also reduce the\npatch size a bit, but may allow someone to add an insane item to\nthe list.\n\n> > +static int supports_feature(const char *the_feature)\n> \n> And you can perform a bsearch here. instead of linear.\n\nSure. But I'm actually expecting more for Porcelain that cares\nto run `git version --list-features` and store that output into\nits own internal table, then consult that table rather than the\n--supports-feature option. I figured the bsearch would take more\ncode than the linear, and probably wasn't worth it in this dark\nlittle corner of Git.\n\n> > +test_expect_failure \\\n> > +\t'feature \"THISNEVERWILLBEAGITFEATURE\" is not supported' \\\n> > +\t'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'\n> \n> I would expect that THISNEW... will get complaint saying \"That\n> is not a valid feature name, as it has uppercase\", from a\n> version that has is_feature_name_sane() function.\n\nEh, probably true. I guess I should make that lowercase so it is\nactually a sane name, just one so unlikely that we will never use it.\n \n> I suspect that this patch is meant for my 'maint' (and\n> 1.5.2.3). Or is it for my 'master'? What's your plan to handle\n> transition?\n\nEh, sorry, I should have mentioned that. I meant for you to apply\nthis to your master, where `git blame -w` is already present.\n\nCurrently with next I get:\n\n $ git version --list-features\n git version 1.5.2.2.1050.g51a8b\n\nSo what I was planning on doing in git-gui was running that, and if\nI just get one line with `git version` on it (which is an insane\nfeature name btw) then I know --list-features is not supported,\nand neither is any other feature that I might be looking for from\nthe --list-features command.\n\nOn the other hand if --list-features is actually supported instead\nI'll get back at least a line with \"list-features\" on it, and I\nwon't get a line with \"git version\" on it (as that is an insane\nfeature name).\n\nI guess it is good that our cmd_version() routine never actually\nchecked to see if its argv[] matched what it expects to receive\n(nothing up until now). :)\n\nNow I'm fine with you applying this back into a 1.5.2.x maint\nrelease, but because of the cmd_version() behavior I don't think\nthat is really required. Nor am I looking for you to cherry-pick\nback the `git blame -w` feature.\n \n> If this is meant to be only for 1.5.3 and later, then you know\n> that \"blame -w\" is available as well, so the fact you can do\n> \"git version --list-features\" alone tells you that you can use\n> \"blame -w\", among other many things, such as \"diff -C -C\"\n> instead of --find-copies-harder.\n\nYes, that is true.\n \n> Where does the above discussion lead us? It essentially means,\n> in either case, \"blame-ignore-whitespace\" should not be in that\n> supported_features[] array.\n\nHmm. So assuming that is true, under what rule do you propose we\nadd new features to that array in the future? And what name(s)\ndo we give to them?\n\nFor a recent hypothetical example, assume this patch was already\napplied in your master by the time Linus submitted his useful hack\n`git log --follow`. How would we signal in the supported_features[]\nthat log would understand --follow for a single file pathname?\n\n-- \nShawn.\n"},{"id":"45474","messageId":"7vr6o5zt76.fsf@assigned-by-dhcp.pobox.com","threadId":"8671","inReplyTo":"20070621061045.GG8477@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-21T07:02:05Z","receivedAt":"2007-06-21T07:02:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> If you want to be less defensive, OK, it would also reduce the\n> patch size a bit, but may allow someone to add an insane item to\n> the list.\n\nIf we were to go this route (which I am not convinced is the\nright direction yet---using \"git version\" to check the version\nand say \"1.5.3 has blame -w\" might be easier to manage, and that\nneeds to be maintained only by the tools that care about the\nparticular feature, \"blame -w\"), we will potentially be talking\nabout hundreds of features in the long run. I would rather want\nto automate this even further, as keeping the feature list and\nfeatures together would become huge maintenance headache.\n\nSo, first of all, I would want the list of features in\nsupported_features[] to come from a separate file, whose sole\npurpose is to have that list. I would even suggest making it an\ngenerated file, which depends on the source files (not\nnecessarily limited to C files), and built from within the build\nprocedure.\n\nWhenever you add a new command line option, you would add a\ngreppable comment near it, something like...\n\n \t\telse if (!strcmp(\"-s\", arg))\n \t\t\toutput_option |= OUTPUT_NO_AUTHOR;\n+\t\t/* FEATURE[[[blame-ignore-whitespace]]] */\n+\t\telse if (!strcmp(\"-w\", arg))\n+\t\t\txdl_opts |= XDF_IGNORE_WHITESPACE;\n \t\telse if (!strcmp(\"-S\", arg) && ++i < argc)\n \t\t\trevs_file = argv[i];\n\nand have Makefile extract them, sort them and build the meat of\nsupported_features[] array automatically.\n\nUnless we have something like that, I have to worry about merge\nconflicts every time a new topic graduates to 'master'.\n\n>> > +static int supports_feature(const char *the_feature)\n>> \n>> And you can perform a bsearch here. instead of linear.\n>\n> Sure. But I'm actually expecting more for Porcelain that cares\n> to run `git version --list-features` and store that output into\n> its own internal table,\n\nOk, that is probably a sane assumption.\n\n> .... I figured the bsearch would take more\n> code than the linear, and probably wasn't worth it in this dark\n> little corner of Git.\n\nHuh? Don't you already have compar() function that bsearch(3)\ncan take?\n\n>> I suspect that this patch is meant for my 'maint' (and\n>> 1.5.2.3). Or is it for my 'master'? What's your plan to handle\n>> transition?\n>\n> Eh, sorry, I should have mentioned that. I meant for you to apply\n> this to your master, where `git blame -w` is already present.\n>\n> Currently with next I get:\n>\n> $ git version --list-features\n> git version 1.5.2.2.1050.g51a8b\n>\n> So what I was planning on doing in git-gui was running that, and if\n> I just get one line with `git version` on it (which is an insane\n> feature name btw) then I know --list-features is not supported,\n> and neither is any other feature that I might be looking for from\n> the --list-features command.\n>\n> On the other hand if --list-features is actually supported instead\n> I'll get back at least a line with \"list-features\" on it, and I\n> won't get a line with \"git version\" on it (as that is an insane\n> feature name).\n\nThe explaination why \"futureproofing\" is unnecessary for 'maint'\nis good, but that does not necessarily mean --list-featues would\nneed to list _all_ the features in the version that supports\nthat. \"blame -w\" is in 'master' already, for example. Is\n\"have-mergetool\" a feature? Yes, it is. But you already know\nthe command exists if \"git version\" knows --list-features.\n\n> Hmm. So assuming that is true, under what rule do you propose we\n> add new features to that array in the future? And what name(s)\n> do we give to them?\n\nAssuming if this --list-features is a viable approach in the\nlong run, my gut feeling of relative order of things is:\n\n (1) We prepare rock-solid runtime with an _EMPTY_ feature array\n in 'master'.\n\n (2) We add automated feature array management in 'master', as\n outlined above.\n\n (3) Merge the above two to 'next'.\n\n (4) Update all existing topics, including the ones that are\n already in 'next', with the feature mark-up in comment\n (i.e. \"FEATURE[[[feature-name]]]\").\n\nAfter (3) happens, any new topics that introduce a new feature\nshould be accompanied with the feature mark-up.\n\nWhen an update appears on 'master' _after_ (1) and (2) happens\n_but_ Porcelain writers like yourself do not realize that the\nfeature would be _very_ helpful for their Porcelains, and would\nwant to be able to tell if it exists via --list-features, long\nafter we start to support the feature, we might retroactively\nhave to add the feature mark-up. There will be gap between the\ncommit that actually introduce and make the feature usable, and\nthe commit that teaches \"git version\" to talk about it in such a\ncase. But I think that should be Ok.\n\nI do not think we want to keep track of every little \"features\"\nif no Porcelain cares about it.\n\nHere is a list of potential \"feature names\", from the latest\n\"What's cooking\" message.\n\n log-unlimited-message\n log-follow\n oneline-first-paragraph\n svn-merge-local\n work-tree-environ\n filter-branch\n"},{"id":"45480","messageId":"7vhcp1y954.fsf_-_@assigned-by-dhcp.pobox.com","threadId":"8671","inReplyTo":"7vr6o5zt76.fsf@assigned-by-dhcp.pobox.com","subject":"[PATCH] Make list of features auto-managed.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-21T09:00:39Z","receivedAt":"2007-06-21T09:00:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This updates the build procedure so that a mark-up in the form\nof:\n\n\tSP \"FEATURE<\" feature-name \">\" SP\n\nis picked up from the sources, in order to help keeping\nsupported_features[] array automatically in sync.\n\nSigned-off-by: Junio C Hamano \n---\n\n Junio C Hamano writes:\n\n > So, first of all, I would want the list of features in\n > supported_features[] to come from a separate file, whose sole\n > purpose is to have that list. I would even suggest making it an\n > generated file, which depends on the source files (not\n > necessarily limited to C files), and built from within the build\n > procedure.\n > ...\n > Assuming if this --list-features is a viable approach in the\n > long run, my gut feeling of relative order of things is:\n >\n > (1) We prepare rock-solid runtime with an _EMPTY_ feature array\n > in 'master'.\n >\n > (2) We add automated feature array management in 'master', as\n > outlined above.\n >\n > (3) Merge the above two to 'next'.\n >\n > (4) Update all existing topics, including the ones that are\n > already in 'next', with the feature mark-up in comment\n > (i.e. \"FEATURE[[[feature-name]]]\").\n >\n > After (3) happens, any new topics that introduce a new feature\n > should be accompanied with the feature mark-up.\n\n So here is a PoC for step (2). It loses more lines than it\n adds, primarily because we can lose is_feature_name_sane(); it\n is done at the build time now.\n\n .gitignore | 1 +\n Makefile | 12 +++++++++++-\n builtin-blame.c | 1 +\n generate-features.sh | 9 +++++++++\n help.c | 48 +++++++++++++-----------------------------------\n 5 files changed, 35 insertions(+), 36 deletions(-)\n create mode 100755 generate-features.sh\n\ndiff --git a/.gitignore b/.gitignore\nindex e8b060c..64ee08b 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -169,3 +169,4 @@ config.status\n config.mak.autogen\n config.mak.append\n configure\n+features.h\ndiff --git a/Makefile b/Makefile\nindex c09dfaf..d8d1ddc 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -262,6 +262,13 @@ BUILT_INS = \\\n \tgit-fsck-objects$X git-cherry-pick$X \\\n \t$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))\n \n+# what are the source files\n+SOURCE_FILES = $(sort \\\n+\t$(SCRIPT_SH) $(SCRIPT_PERL) $(SCRIPT_PYTHON) \\\n+\t$(patsubst git-%$X,%.c,$(PROGRAMS)) \\\n+\t$(LIB_H) \\\n+\t$(patsubst %.o,%.c,$(LIB_OBJS) $(BUILTIN_OBJS)))\n+\n # what 'all' will build and 'install' will install, in gitexecdir\n ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)\n \n@@ -755,7 +762,10 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)\n \t\t$(ALL_CFLAGS) -o $@ $(filter %.c,$^) git.o \\\n \t\t$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)\n \n-help.o: common-cmds.h\n+features.h: $(SOURCE_FILES) generate-features.sh\n+\t$(QUIET_GEN)./generate-features.sh $(SOURCE_FILES) > $@+ && mv $@+ $@\n+\n+help.o: common-cmds.h features.h\n \n git-merge-subtree$X: git-merge-recursive$X\n \t$(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex f7e2c13..c84d96a 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -2162,6 +2162,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \t\telse if (!strcmp(\"-s\", arg))\n \t\t\toutput_option |= OUTPUT_NO_AUTHOR;\n \t\telse if (!strcmp(\"-w\", arg))\n+\t\t\t/* FEATURE */\n \t\t\txdl_opts |= XDF_IGNORE_WHITESPACE;\n \t\telse if (!strcmp(\"-S\", arg) && ++i < argc)\n \t\t\trevs_file = argv[i];\ndiff --git a/generate-features.sh b/generate-features.sh\nnew file mode 100755\nindex 0000000..674c5fe\n--- /dev/null\n+++ b/generate-features.sh\n@@ -0,0 +1,9 @@\n+#!/bin/sh\n+#\n+# New features that Porcelains may care about can be marked in the\n+# source code with FEATURE. This script is driven\n+# by Makefile to pick them out and sort them to prepare features.h\n+# file, which is included by help.c.\n+\n+sed -n -e 's|.* FEATURE<\\([a-z0-9][-a-z0-9]*[a-z0-9]\\)> .*/| \"\\1\",|p' \"$@\" |\n+sort -u\ndiff --git a/help.c b/help.c\nindex d050cbf..b0887ea 100644\n--- a/help.c\n+++ b/help.c\n@@ -9,9 +9,10 @@\n #include \"common-cmds.h\"\n #include \n \n+/* FEATURE */\n+\n static const char *supported_features[] = {\n-\t\"blame-ignore-whitespace\",\n-\t\"list-features\",\n+#include \"features.h\"\n };\n \n /* most GUI terminals set COLUMNS (although some don't export it) */\n@@ -195,51 +196,28 @@ void help_unknown_cmd(const char *cmd)\n \texit(1);\n }\n \n-static int is_feature_name_sane(const char *a)\n+static void list_features(void)\n {\n-\tif (!*a || *a == '-')\n-\t\treturn 0;\n-\tfor (; *a; a++) {\n-\t\tif (! ((*a >= 'a' && *a <= 'z')\n-\t\t || (*a >= '0' && *a <= '9')\n-\t\t || *a == '-'))\n-\t\t\treturn 0;\n-\t}\n-\treturn 1;\n+\tunsigned cnt = ARRAY_SIZE(supported_features);\n+\tunsigned i;\n+\n+\tfor (i = 0; i < cnt; i++)\n+\t\tprintf(\"%s\\n\", supported_features[i]);\n }\n \n static int cmp_feature(const void *a_, const void *b_)\n {\n \tconst char *a = *((const char **)a_);\n \tconst char *b = *((const char **)b_);\n-\treturn strcmp(a, b);\n-}\n \n-static void list_features()\n-{\n-\tunsigned cnt = ARRAY_SIZE(supported_features);\n-\tunsigned i;\n-\n-\tqsort(supported_features, cnt,\n-\t\tsizeof(supported_features[0]), cmp_feature);\n-\tfor (i = 0; i < cnt; i++) {\n-\t\tconst char *f = supported_features[i];\n-\t\tif (!is_feature_name_sane(f))\n-\t\t\tdie(\"feature name \\\"%s\\\" is bogus\", f);\n-\t\tprintf(\"%s\\n\", f);\n-\t}\n+\treturn strcmp(a, b);\n }\n \n static int supports_feature(const char *the_feature)\n {\n-\tunsigned cnt = ARRAY_SIZE(supported_features);\n-\tunsigned i;\n-\n-\tfor (i = 0; i < cnt; i++) {\n-\t\tif (!strcmp(supported_features[i], the_feature))\n-\t\t\treturn 0;\n-\t}\n-\treturn 1;\n+\treturn !bsearch(&the_feature, supported_features,\n+\t\t\t(size_t) ARRAY_SIZE(supported_features),\n+\t\t\tsizeof(const char *), cmp_feature);\n }\n \n static const char version_usage[] =\n-- \n1.5.2.2.1050.g51a8b\n"},{"id":"45481","messageId":"7vwsxxwtrh.fsf@assigned-by-dhcp.pobox.com","threadId":"8671","inReplyTo":"7vhcp1y954.fsf_-_@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-21T09:18:10Z","receivedAt":"2007-06-21T09:18:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I am now getting sort of convinced that the list-features is a\nslippery slop towards total suckage, unless managed very\ncarefully.\n\nThe \"auto manage\" patch I am responding to would tempt anybody\nto extend the mechanism to do something like the attached patch,\nbecause a one-line comment near the code, like:\n\n\t/* FEATURE */\n\ndoes not look very useful nor pretty by itself in the source\ncode. It makes it very tempting to actually describe the\n\"feature\". People with only half a brain would even advocate\nupdating supported_features[] to a tuple of (name, explanation),\nand have \"git version --list-features\" to spit both out, or\nsomething like that. I really do not think we would want to go\nthere.\n\nA few years down the road, do we really care if we did not do\nsomething long time ago, but the code was updated and added as a\nnew feature? That information belongs to the commit log, not to\nin-source comments. This will lead to the same mistake often\nmade by users of other SCMs, embedding \"$Log$\" in their sources.\n\n\n=== sample diff that is not acceptable ===\n\ndiff --git a/commit.c b/commit.c\nindex dbb28b5..4b713b6 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -1016,6 +1016,12 @@ static void pp_header(enum cmit_fmt fmt,\n \t}\n }\n \n+/*\n+ * FEATURE: we used to treat the first line of the\n+ * commit messages special, but messages imported from foreign culture often\n+ * have more than one line in the first \"paragraph\". We now treat the\n+ * first paragraph as special for the purposes of --pretty=oneline.\n+ */\n static void pp_title_line(enum cmit_fmt fmt,\n \t\t\t const char **msg_p,\n \t\t\t unsigned long *len_p,\n@@ -1140,6 +1146,11 @@ static void pp_remainder(enum cmit_fmt fmt,\n \t}\n }\n \n+/*\n+ * FEATURE: we used to have a hard limit\n+ * of 16kB message, but that is sometimes not enough for huge commits\n+ * imported from foreign culture. We now dynamically grow the buffer.\n+ */\n unsigned long pretty_print_commit(enum cmit_fmt fmt,\n \t\t\t\t const struct commit *commit,\n \t\t\t\t unsigned long len,\n"},{"id":"45488","messageId":"Pine.LNX.4.64.0706211257060.4059@racer.site","threadId":"8671","inReplyTo":"7vr6o5zt76.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-21T11:58:17Z","receivedAt":"2007-06-21T11:58:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 21 Jun 2007, Junio C Hamano wrote:\n\n> [...] using \"git version\" to check the version and say \"1.5.3 has blame \n> -w\" > might be easier to manage [ than list-features maintenance ...]\n\nWe do something similar already with curl features. So this sounds \nsensible to me. Shawn?\n\nCiao,\nDscho\n"},{"id":"45510","messageId":"alpine.LFD.0.99.0706211137020.20596@xanadu.home","threadId":"8671","inReplyTo":"7vwsxxwtrh.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-21T15:55:46Z","receivedAt":"2007-06-21T15:55:46Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 21 Jun 2007, Junio C Hamano wrote:\n\n> I am now getting sort of convinced that the list-features is a\n> slippery slop towards total suckage, unless managed very\n> carefully.\n> \n> The \"auto manage\" patch I am responding to would tempt anybody\n> to extend the mechanism to do something like the attached patch,\n> because a one-line comment near the code, like:\n> \n> \t/* FEATURE */\n> \n> does not look very useful nor pretty by itself in the source\n> code. It makes it very tempting to actually describe the\n> \"feature\". People with only half a brain would even advocate\n> updating supported_features[] to a tuple of (name, explanation),\n> and have \"git version --list-features\" to spit both out, or\n> something like that. I really do not think we would want to go\n> there.\n> \n> A few years down the road, do we really care if we did not do\n> something long time ago, but the code was updated and added as a\n> new feature? That information belongs to the commit log, not to\n> in-source comments. This will lead to the same mistake often\n> made by users of other SCMs, embedding \"$Log$\" in their sources.\n\nWell, just in case my opinion matters...\n\nI don't like this feature list idea at all.\n\nNot only is it going to grow indefinitely with no possibility for \ngarbage collection because programs will depends on particular features \nto be listed there, the simple fact that deciding if a particular \nimprovement should be listed is a subjective matter which will make the \nlist grow faster than it absolutely should.\n\nGiven that this appears to be needed by git-guy, and since git-guy is \nshipped with main git already, it is a bit odd to have to support code \nto work with older git versions. Why isn't git-guy simply remaining in \nsynch with the git version it is shipped with? This way cruft won't \naccumulate forever.\n\nAnd if the tool and git core really have to be decoupled, then the best \nway to test for a specific feature is actually to get the git \nversion. No silly issues with a feature list to maintain, and no issue \nwith a particular feature that might not have been added to the list. \n\nWhen you need git behavior X and you know that it appeared in version Y \nthen you only need to test for git_version >= Y. Determining that \nparticular Y is much easier after the facts using the commit log than \ntrying to anticipate what item should be added to a feature list for \nfuture usage. In fact the same argument as for not explicitly recording \nrenames in commit objects should apply here.\n\n\nNicolas\n"},{"id":"45524","messageId":"7v7ipxw1bq.fsf@assigned-by-dhcp.pobox.com","threadId":"8671","inReplyTo":"alpine.LFD.0.99.0706211137020.20596@xanadu.home","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-21T19:32:25Z","receivedAt":"2007-06-21T19:32:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Well, just in case my opinion matters...\n\nWell, you already do ;-)\n\n> I don't like this feature list idea at all.\n\n... and thanks for bringing a bit of sanity to this thread.\n\n> When you need git behavior X and you know that it appeared in version Y \n> then you only need to test for git_version >= Y. Determining that \n> particular Y is much easier after the facts using the commit log than \n> trying to anticipate what item should be added to a feature list for \n> future usage. In fact the same argument as for not explicitly recording \n> renames in commit objects should apply here.\n\nVery well put; that is exactly what I wanted to say in two\nmessages ago.\n"},{"id":"45540","messageId":"20070622032502.GA17393@spearce.org","threadId":"8671","inReplyTo":"7v7ipxw1bq.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-22T03:25:02Z","receivedAt":"2007-06-22T03:25:02Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> > I don't like this feature list idea at all.\n> \n> ... and thanks for bringing a bit of sanity to this thread.\n\nIndeed. I've read Junio's counter proposal (the grep'ed FEATURE\nmacro) and I'm now convinced you are both right, this feature list\nthing is just going to grow out of control or nobody is going to\nmark new features. Either way its useless for its intended purpose.\n \n> > When you need git behavior X and you know that it appeared in version Y \n> > then you only need to test for git_version >= Y. Determining that \n> > particular Y is much easier after the facts using the commit log than \n> > trying to anticipate what item should be added to a feature list for \n> > future usage. In fact the same argument as for not explicitly recording \n> > renames in commit objects should apply here.\n\nHere's the problem though: `git-blame -w` will be supported\nin Git 1.5.3 and later, we all know this. But Git doesn't.\nAsk git-describe what version `master` and `next` are; its\nv1.5.2.2-249 and v1.5.2.2-1050.\n\nSo tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and\n1.5.3 is OK, but 1.5.2.3 isn't? Actually its 1.5.2.1.160 that is\nOK (b82871b introduced the -w option). Sure Junio won't release\na 1.5.2.1.160 as an actual tagged release (160 patch releases to\n1.5.2.1 is nuts). But what about in the future if a cool feature\n3 commits past 1.5.3 appears? Wouldn't that look like 1.5.3.3,\nand isn't that a possibly valid version number?\n\nBesides, I can't say 1.5.2.3 is >= 1.5.2.2.249, because in git.git\nit isn't. Only 1.5.3 will be >= 1.5.2.2.249.\n\n\nNico mentioned that git-gui ships with git.git, and therefore should\njust rely on exactly whatever that git.git supports at the time of\nthe merge. I think that is only partially valid. git-gui is also\nan independent project with a repository and history that exists\noutside of git.git. Users can (and should be able to) mix and\nmatch the version of git-gui with the version of plumbing, to the\nmaximum extent possible. I'd like to at least gracefully fail by\ndisabling an option, or suggesting the user upgrade their plumbing,\nif an option isn't supported.\n\nUnlike how we gracefully fail with a useful error message say\nwhen an early 1.4 release that doesn't support offset deltas is\ngiven a packfile with an OFS_DELTA in it (corrupt pack, recently\nrediscussed on list). Or when a 1.5.1 client tries to checkout\na tree that uses the new subproject mode in 1.5.2 (missing blob,\nrecently discussed on #git).\n\nMaybe I should ask the StGIT folks how they deal with this, or if\nthey just don't worry about it. I'm suspecting its the latter...\n\n\nHmm.\n\n-- \nShawn.\n"},{"id":"45543","messageId":"7v4pl0bpxq.fsf@assigned-by-dhcp.pobox.com","threadId":"8671","inReplyTo":"20070622032502.GA17393@spearce.org","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-22T03:58:41Z","receivedAt":"2007-06-22T03:58:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Here's the problem though: `git-blame -w` will be supported\n> in Git 1.5.3 and later, we all know this. But Git doesn't.\n> Ask git-describe what version `master` and `next` are; its\n> v1.5.2.2-249 and v1.5.2.2-1050.\n>\n> So tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and\n> 1.5.3 is OK, but 1.5.2.3 isn't?\n\nYou don't. Although 1.5.2.2.249 may have it, you do not enable\nit for that version.\n\nThat is what \"1.5.3 or later\" implies. And in 6 weeks that\nlittle distinction does not matter.\n\nPretty simple.\n"},{"id":"45545","messageId":"alpine.LFD.0.99.0706212337030.20596@xanadu.home","threadId":"8671","inReplyTo":"20070622032502.GA17393@spearce.org","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-22T04:07:35Z","receivedAt":"2007-06-22T04:07:35Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 21 Jun 2007, Shawn O. Pearce wrote:\n\n> > Nicolas Pitre writes:\n> > > When you need git behavior X and you know that it appeared in version Y \n> > > then you only need to test for git_version >= Y. Determining that \n> > > particular Y is much easier after the facts using the commit log than \n> > > trying to anticipate what item should be added to a feature list for \n> > > future usage. In fact the same argument as for not explicitly recording \n> > > renames in commit objects should apply here.\n> \n> Here's the problem though: `git-blame -w` will be supported\n> in Git 1.5.3 and later, we all know this. But Git doesn't.\n> Ask git-describe what version `master` and `next` are; its\n> v1.5.2.2-249 and v1.5.2.2-1050.\n> \n> So tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and\n> 1.5.3 is OK, but 1.5.2.3 isn't? Actually its 1.5.2.1.160 that is\n> OK (b82871b introduced the -w option). Sure Junio won't release\n> a 1.5.2.1.160 as an actual tagged release (160 patch releases to\n> 1.5.2.1 is nuts). But what about in the future if a cool feature\n> 3 commits past 1.5.3 appears? Wouldn't that look like 1.5.3.3,\n> and isn't that a possibly valid version number?\n> \n> Besides, I can't say 1.5.2.3 is >= 1.5.2.2.249, because in git.git\n> it isn't. Only 1.5.3 will be >= 1.5.2.2.249.\n\nFirst of all, I mentioned at the time that using a . for separator \nbetween the tagged version and the number of commits since then in the \ngit-describe output was a bad idea. You just made the perfect \ndemonstration of that. If it was just me I'd change that . for a + or a \n: like the original patch did.\n\nNow to your issue. I think that if you must rely upon a particular \nversion then it's best if it is a released version. Intermediate \nversions as provided by git-describe aren't reliable enough to provide \na proper number to test against, especially in the presence of \nconcurrent branches. The 1.6.0+38 (let me use a saner output) from the \nmaster branch is totally different from 1.6.0+38 from the 'next' branch. \nSo only released versions should be used to compare against.\n\nNow you say that you don't want to wait for the release to happen before \nusing this cool new feature. Well, I'd reply that life is tough. \nEither you \ntrick Junio into making a release sooner because the feature is just too \nvaluable to wait. Or you try the feature (git-blame -w) and hope for \nthe best. Certainly in that case you can predict the behavior of \nolder git-blame versions if you pass it -w which they don't understand?\n\n> Nico mentioned that git-gui ships with git.git, and therefore should\n> just rely on exactly whatever that git.git supports at the time of\n> the merge. I think that is only partially valid. git-gui is also\n> an independent project with a repository and history that exists\n> outside of git.git. Users can (and should be able to) mix and\n> match the version of git-gui with the version of plumbing, to the\n> maximum extent possible. \n\nFair enough.\n\n> I'd like to at least gracefully fail by\n> disabling an option, or suggesting the user upgrade their plumbing,\n> if an option isn't supported.\n\nWell you should be able to just try the option and detect it when it \nisn't supported.\n\n> Unlike how we gracefully fail with a useful error message say\n> when an early 1.4 release that doesn't support offset deltas is\n> given a packfile with an OFS_DELTA in it (corrupt pack, recently\n> rediscussed on list). Or when a 1.5.1 client tries to checkout\n> a tree that uses the new subproject mode in 1.5.2 (missing blob,\n> recently discussed on #git).\n\nThose are different as you have an older version that couldn't \nanticipate the future. In your case you can \"anticipate the past\".\n\n\nNicolas\n"},{"id":"45546","messageId":"20070622043329.GE17393@spearce.org","threadId":"8671","inReplyTo":"alpine.LFD.0.99.0706212337030.20596@xanadu.home","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-22T04:33:29Z","receivedAt":"2007-06-22T04:33:29Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> First of all, I mentioned at the time that using a . for separator \n> between the tagged version and the number of commits since then in the \n> git-describe output was a bad idea. You just made the perfect \n> demonstration of that. If it was just me I'd change that . for a + or a \n> : like the original patch did.\n\nI preferred + as well, but we wound up with - in the final patch,\nand GIT-VERSION-GEN replaces the - with a . because that makes RPM\nhappier or something:\n\n VN=$(echo \"$VN\" | sed -e 's/-/./g');\n\n> Now you say that you don't want to wait for the release to happen before \n> using this cool new feature. Well, I'd reply that life is tough. \n\nIn comparsion to other things we all must deal with in life, this\nis a cakewalk. ;-) But yes, your point is well made.\n\n> Either you \n> trick Junio into making a release sooner because the feature is just too \n> valuable to wait. Or you try the feature (git-blame -w) and hope for \n> the best. Certainly in that case you can predict the behavior of \n> older git-blame versions if you pass it -w which they don't understand?\n\nI think that's where we are. I can develop the feature, trick\ngit-gui into enabling it, but most end-users won't be able to use\nit until Junio makes a 1.5.3-rc* or 1.5.3 final. Tough for them.\nTricking Junio is very hard, he isn't easily tricked. A good\nquality for a mantainer to have.\n\n> > I'd like to at least gracefully fail by\n> > disabling an option, or suggesting the user upgrade their plumbing,\n> > if an option isn't supported.\n> \n> Well you should be able to just try the option and detect it when it \n> isn't supported.\n\nSure.\n\nExcept sometimes we have been lax about option checking and don't\nalways fail (though we usually do, but haven't always). And on\nWindows doing a fork+exec to poll an option is expensive. Worse,\nsome options are destructive. For example `update-ref -d`.\n\nShould I run `update-ref -d refs/heads/master` to see if the\n-d option is supported by update-ref, so that I know if I should\ncreate a particular UI widget or not? No, of course not. I should\nuse a special temporary name, like GITGUI_TEST_FEATURE. But now\nI have to create and delete a temporary item just to decide if a\nUI feature should be enabled. And if the feature doesn't exist,\nthen I have to cleanup the temporary item \"by hand\".\n\nAnnoying. Like this email thread I'm sure has become.\n \n> > Unlike how we gracefully fail with a useful error message say\n> > when an early 1.4 release that doesn't support offset deltas is\n> > given a packfile with an OFS_DELTA in it (corrupt pack, recently\n> > rediscussed on list). Or when a 1.5.1 client tries to checkout\n> > a tree that uses the new subproject mode in 1.5.2 (missing blob,\n> > recently discussed on #git).\n> \n> Those are different as you have an older version that couldn't \n> anticipate the future. In your case you can \"anticipate the past\".\n\nYes, however my point here is that I think we have historically\nbeen bad about making our software reasonably future-proof.\n\nThe .pack file has a version field, with value 2. REF_DELTA is not\nsupported by those binaries that predated its introduction. They are\nunable to properly unpack, index or read a packfile using REF_DELTA.\nWhy did the .pack version stay at 2 if REF_DELTA is used in the file?\n\nThe packed-refs file was introduced without a version header\n(whoops). Later Junio had to wedge things into there in order to\nget a version header of sorts so we could have the tag deref values\ncached in the packed-refs.\n\nWe weren't strict enough in checking file modes in the tree parser\n(yes, that was actually a real bug) but basically we didn't think\nahead to what an older binary should do when a future binary used a\nfile mode we didn't understand. For example, the user setuid bit.\nOr the new dirlink thing, which isn't even a valid mode in UNIX.\n\nI think we are getting a little better at it, but in general we\nhave a really poor track record in this area.\n\n-- \nShawn.\n"},{"id":"45548","messageId":"alpine.LFD.0.99.0706220103090.20596@xanadu.home","threadId":"8671","inReplyTo":"20070622043329.GE17393@spearce.org","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-22T05:15:15Z","receivedAt":"2007-06-22T05:15:15Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 22 Jun 2007, Shawn O. Pearce wrote:\n\n> Yes, however my point here is that I think we have historically\n> been bad about making our software reasonably future-proof.\n> \n> The .pack file has a version field, with value 2. REF_DELTA is not\n> supported by those binaries that predated its introduction. They are\n> unable to properly unpack, index or read a packfile using REF_DELTA.\n> Why did the .pack version stay at 2 if REF_DELTA is used in the file?\n\nBecause:\n\n1) you wouldn't be able to properly unpack, index or read a pack file \n using those deltas even with a different pack version _anyway_, and\n\n2) the pack encoding itself has not changed at all.\n\nAnd #2 is real. The introduction of an additional object type didn't \nturn the pack content into something that old git versions could \n(mis)interpret and be fooled by.\n\nOn the other hand, changes leading to pack version 3 really required a \npack version bump as those changes could really be misinterpreted by \nolder git versions.\n\nThe fact that old git versions call the pack corrupt when it contains \nunknown objects is a problem with the error message not the pack \nversion. We even had a bad error message for unknown pack versions too \nbefore you improved it.\n\n\nNicolas\n"},{"id":"45557","messageId":"200706221159.20395.Josef.Weidendorfer@gmx.de","threadId":"8671","inReplyTo":"20070622043329.GE17393@spearce.org","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-22T09:59:20Z","receivedAt":"2007-06-22T09:59:20Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 22 June 2007, Shawn O. Pearce wrote:\n> > Now you say that you don't want to wait for the release to happen before \n> > using this cool new feature. Well, I'd reply that life is tough. \n> \n> In comparsion to other things we all must deal with in life, this\n> is a cakewalk. ;-) But yes, your point is well made.\n\nHmm... Perhaps I am missing something.\n\nIMHO this discussion is about how to cope with different versions of two\nprograms depending on each other, but being released in a loosely coupled way\n(this is a problem Xorg now has with their independent releases of Xorg modules).\n\nHowever, git-gui is released together with git (also in the foreseeable\nfuture, even if we use submodules some day).\nAnd therefore, a git user always will get installations of matching versions\nof git and git-gui; this is even true for developers who run \"make install\"\nin git source.\n\nSo IMHO there is no version check needed at all in this case. Anybody who\nis installing git in strange partial ways should expect to be screwed.\n\nJosef\n"},{"id":"45570","messageId":"tnxabusqe6r.fsf@arm.com","threadId":"8671","inReplyTo":"20070622032502.GA17393@spearce.org","subject":"Re: [PATCH] Make list of features auto-managed.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2007-06-22T14:03:24Z","receivedAt":"2007-06-22T14:03:24Z","isPatch":true,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"\"Shawn O. Pearce\" wrote:\n> Here's the problem though: `git-blame -w` will be supported\n> in Git 1.5.3 and later, we all know this. But Git doesn't.\n> Ask git-describe what version `master` and `next` are; its\n> v1.5.2.2-249 and v1.5.2.2-1050.\n[...]\n> Maybe I should ask the StGIT folks how they deal with this, or if\n> they just don't worry about it. I'm suspecting its the latter...\n\nWe don't worry much about it. We actually try to be compatible with\nsome older versions and not use much of the new features in GIT (StGIT\nuses a small subset anyway - see stgit/git.py).\n\n-- \nCatalin\n"}]}