This project is mirrored from https://github.com/git/git.git. Pull mirroring updated .
  1. 25 Sep, 2017 2 commits
  2. 15 Jun, 2017 1 commit
  3. 30 May, 2017 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      C style: use standard style for "TRANSLATORS" comments · 66f5f6dc
      Ævar Arnfjörð Bjarmason authored
      Change all the "TRANSLATORS: [...]" comments in the C code to use the
      regular Git coding style, and amend the style guide so that the
      example there uses that style.
      
      This custom style was necessary back in 2010 when the gettext support
      was initially added, and was subsequently documented in commit
      cbcfd4e3 ("i18n: mention "TRANSLATORS:" marker in
      Documentation/CodingGuidelines", 2014-04-18).
      
      GNU xgettext hasn't had the parsing limitation that necessitated this
      exception for almost 3 years. Since its 0.19 release on 2014-06-02
      it's been able to recognize TRANSLATOR comments in the standard Git
      comment syntax[1].
      
      Usually we'd like to keep compatibility with software that's that
      young, but in this case literally the only person who needs to be
      using a gettext newer than 3 years old is Jiang Xin (the only person
      who runs & commits "make pot" results), so I think in this case we can
      make an exception.
      
      This xgettext parsing feature was added after a thread on the Git
      mailing list[2] which continued on the bug-gettext[3] list, but we
      never subsequently changed our style & styleguide, do so.
      
      There are already longstanding changes in git that use the standard
      comment style & have their TRANSLATORS comments extracted properly
      without getting the literal "*"'s mixed up in the text, as would
      happen before xgettext 0.19.
      
      Commit 7ff26832 ("builtin-am: implement -i/--interactive",
      2015-08-04) added one such comment, which in commit df0617bf ("l10n:
      git.pot: v2.6.0 round 1 (123 new, 41 removed)", 2015-09-05) got picked
      up in the po/git.pot file with the right format, showing that Jiang
      already runs a modern xgettext.
      
      The xgettext parser does not handle the sort of non-standard comment
      style that I'm amending here in sequencer.c, but that isn't standard
      Git comment syntax anyway. With this change to sequencer.c & "make
      pot" the comment in the pot file is now correct:
      
           #. TRANSLATORS: %s will be "revert", "cherry-pick" or
          -#. * "rebase -i".
          +#. "rebase -i".
      
      1. http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=10af7fe6bd
      2. <2ce9ec4[email protected]gmail.com>
         (https://public-inbox.org/git/2ce9ec4[email protected]gmail.com/)
      3. https://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00016.htmlSigned-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <[email protected]>
      Acked-by: Jiang Xin's avatarJiang Xin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      66f5f6dc
  4. 21 Mar, 2017 2 commits
    • Jeff King's avatar
      prefix_filename: return newly allocated string · e4da43b1
      Jeff King authored
      The prefix_filename() function returns a pointer to static
      storage, which makes it easy to use dangerously. We already
      fixed one buggy caller in hash-object recently, and the
      calls in apply.c are suspicious (I didn't dig in enough to
      confirm that there is a bug, but we call the function once
      in apply_all_patches() and then again indirectly from
      parse_chunk()).
      
      Let's make it harder to get wrong by allocating the return
      value. For simplicity, we'll do this even when the prefix is
      empty (and we could just return the original file pointer).
      That will cause us to allocate sometimes when we wouldn't
      otherwise need to, but this function isn't called in
      performance critical code-paths (and it already _might_
      allocate on any given call, so a caller that cares about
      performance is questionable anyway).
      
      The downside is that the callers need to remember to free()
      the result to avoid leaking. Most of them already used
      xstrdup() on the result, so we know they are OK. The
      remainder have been converted to use free() as appropriate.
      
      I considered retaining a prefix_filename_unsafe() for cases
      where we know the static lifetime is OK (and handling the
      cleanup is awkward). This is only a handful of cases,
      though, and it's not worth the mental energy in worrying
      about whether the "unsafe" variant is OK to use in any
      situation.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e4da43b1
    • Jeff King's avatar
      prefix_filename: drop length parameter · 116fb64e
      Jeff King authored
      This function takes the prefix as a ptr/len pair, but in
      every caller the length is exactly strlen(ptr). Let's
      simplify the interface and just take the string. This saves
      callers specifying it (and in some cases handling a NULL
      prefix).
      
      In a handful of cases we had the length already without
      calling strlen, so this is technically slower. But it's not
      likely to matter (after all, if the prefix is non-empty
      we'll allocate and copy it into a buffer anyway).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      116fb64e
  5. 14 Dec, 2016 1 commit
    • Jeff King's avatar
      parse-options: print "fatal:" before usage_msg_opt() · 87433261
      Jeff King authored
      Programs may use usage_msg_opt() to print a brief message
      followed by the program usage, and then exit. The message
      isn't prefixed at all, though, so it doesn't match our usual
      error output and is easy to overlook:
      
          $ git clone 1 2 3
          Too many arguments.
      
          usage: git clone [<options>] [--] <repo> [<dir>]
      
          -v, --verbose         be more verbose
          -q, --quiet           be more quiet
          --progress            force progress reporting
          -n, --no-checkout     don't create a checkout
          --bare                create a bare repository
          [...and so on for another 31 lines...]
      
      It looks especially bad when the message starts with an
      option, like:
      
          $ git replace -e
          -e needs exactly one argument
      
          usage: git replace [-f] <object> <replacement>
             or: git replace [-f] --edit <object>
          [...etc...]
      
      Let's put our usual "fatal:" prefix in front of it.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      87433261
  6. 05 May, 2016 1 commit
    • Pranit Bauva's avatar
      parse-options.c: make OPTION_COUNTUP respect "unspecified" values · e0070e8b
      Pranit Bauva authored
      OPT_COUNTUP() merely increments the counter upon --option, and resets it
      to 0 upon --no-option, which means that there is no "unspecified" value
      with which a client can initialize the counter to determine whether or
      not --[no]-option was seen at all.
      
      Make OPT_COUNTUP() treat any negative number as an "unspecified" value
      to address this shortcoming. In particular, if a client initializes the
      counter to -1, then if it is still -1 after parse_options(), then
      neither --option nor --no-option was seen; if it is 0, then --no-option
      was seen last, and if it is 1 or greater, than --option was seen last.
      
      This change does not affect the behavior of existing clients because
      they all use the initial value of 0 (or more).
      
      Note that builtin/clean.c initializes the variable used with
      OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
      to either 0 or 1 by reading the configuration before the code calls
      parse_options(), i.e. as far as parse_options() is concerned, the
      initial value of the variable is not negative.
      
      To test this behavior, in test-parse-options.c, "verbose" is set to
      "unspecified" while quiet is set to 0 which will test the new behavior
      with all sets of values.
      Helped-by: default avatarJeff King <[email protected]>
      Helped-by: Eric Sunshine's avatarEric Sunshine <[email protected]>
      Helped-by: default avatarJunio C Hamano <[email protected]>
      Signed-off-by: Pranit Bauva's avatarPranit Bauva <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e0070e8b
  7. 20 Nov, 2015 3 commits
  8. 22 Jun, 2015 1 commit
    • CB Bailey's avatar
      parse-options: move unsigned long option parsing out of pack-objects.c · 2a514ed8
      CB Bailey authored
      The unsigned long option parsing (including 'k'/'m'/'g' suffix
      parsing) is more widely applicable.  Add support for OPT_MAGNITUDE
      to parse-options.h and change pack-objects.c use this support.
      
      The error behavior on parse errors follows that of OPT_INTEGER.  The
      name of the option that failed to parse is reported with a brief
      message describing the expect format for the option argument and
      then the full usage message for the command invoked.
      
      This differs from the previous behavior for OPT_ULONG used in
      pack-objects for --max-pack-size and --window-memory which used to
      display the value supplied in the error message and did not display
      the full usage message.
      Signed-off-by: CB Bailey's avatarCharles Bailey <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2a514ed8
  9. 04 Sep, 2014 1 commit
    • Junio C Hamano's avatar
      parse-options: detect attempt to add a duplicate short option name · af465af8
      Junio C Hamano authored
      It is easy to overlook an already assigned single-letter option name
      and try to use it for a new one.  Help the developer to catch it
      before such a mistake escapes the lab.
      
      This retroactively forbids any short option name (which is defined
      to be of type "int") outside the ASCII printable range.  We might
      want to do one of two things:
      
       - tighten the type of short_name member to 'char', and further
         update optbug() to protect it against doing "'%c'" on a funny
         value, e.g. negative or above 127.
      
       - drop the check (even the "duplicate" check) for an option whose
         short_name is either negative or above 255, to allow clever folks
         to take advantage of the fact that such a short_name cannot be
         parsed from the command line and the member can be used to store
         some extra information.
      Helped-by: default avatarRené Scharfe <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      af465af8
  10. 20 Jun, 2014 1 commit
    • Jeff King's avatar
      refactor skip_prefix to return a boolean · cf4fff57
      Jeff King authored
      The skip_prefix() function returns a pointer to the content
      past the prefix, or NULL if the prefix was not found. While
      this is nice and simple, in practice it makes it hard to use
      for two reasons:
      
        1. When you want to conditionally skip or keep the string
           as-is, you have to introduce a temporary variable.
           For example:
      
             tmp = skip_prefix(buf, "foo");
             if (tmp)
      	       buf = tmp;
      
        2. It is verbose to check the outcome in a conditional, as
           you need extra parentheses to silence compiler
           warnings. For example:
      
             if ((cp = skip_prefix(buf, "foo"))
      	       /* do something with cp */
      
      Both of these make it harder to use for long if-chains, and
      we tend to use starts_with() instead. However, the first line
      of "do something" is often to then skip forward in buf past
      the prefix, either using a magic constant or with an extra
      strlen(3) (which is generally computed at compile time, but
      means we are repeating ourselves).
      
      This patch refactors skip_prefix() to return a simple boolean,
      and to provide the pointer value as an out-parameter. If the
      prefix is not found, the out-parameter is untouched. This
      lets you write:
      
        if (skip_prefix(arg, "foo ", &arg))
      	  do_foo(arg);
        else if (skip_prefix(arg, "bar ", &arg))
      	  do_bar(arg);
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cf4fff57
  11. 31 Mar, 2014 1 commit
  12. 24 Mar, 2014 1 commit
  13. 10 Mar, 2014 1 commit
  14. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      functions.
      
      The change can be recreated by mechanically applying this:
      
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      59556548
  15. 30 Jul, 2013 1 commit
  16. 11 Feb, 2013 2 commits
  17. 15 Dec, 2012 1 commit
    • Jeff King's avatar
      silence some -Wuninitialized false positives · a469a101
      Jeff King authored
      There are a few error functions that simply wrap error() and
      provide a standardized message text. Like error(), they
      always return -1; knowing that can help the compiler silence
      some false positive -Wuninitialized warnings.
      
      One strategy would be to just declare these as inline in the
      header file so that the compiler can see that they always
      return -1. However, gcc does not always inline them (e.g.,
      it will not inline opterror, even with -O3), which renders
      our change pointless.
      
      Instead, let's follow the same route we did with error() in
      the last patch, and define a macro that makes the constant
      return value obvious to the compiler.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a469a101
  18. 09 Jul, 2012 1 commit
    • Torsten Bögershausen's avatar
      git on Mac OS and precomposed unicode · 76759c7d
      Torsten Bögershausen authored
      Mac OS X mangles file names containing unicode on file systems HFS+,
      VFAT or SAMBA.  When a file using unicode code points outside ASCII
      is created on a HFS+ drive, the file name is converted into
      decomposed unicode and written to disk. No conversion is done if
      the file name is already decomposed unicode.
      
      Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
      result as open("\x41\xcc\x88",...) with a decomposed "Ä".
      
      As a consequence, readdir() returns the file names in decomposed
      unicode, even if the user expects precomposed unicode.  Unlike on
      HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
      precomposed unicode, but readdir() still returns file names in
      decomposed unicode.  When a git repository is stored on a network
      share using SAMBA, file names are send over the wire and written to
      disk on the remote system in precomposed unicode, but Mac OS X
      readdir() returns decomposed unicode to be compatible with its
      behaviour on HFS+ and VFAT.
      
      The unicode decomposition causes many problems:
      
      - The names "git add" and other commands get from the end user may
        often be precomposed form (the decomposed form is not easily input
        from the keyboard), but when the commands read from the filesystem
        to see what it is going to update the index with already is on the
        filesystem, readdir() will give decomposed form, which is different.
      
      - Similarly "git log", "git mv" and all other commands that need to
        compare pathnames found on the command line (often but not always
        precomposed form; a command line input resulting from globbing may
        be in decomposed) with pathnames found in the tree objects (should
        be precomposed form to be compatible with other systems and for
        consistency in general).
      
      - The same for names stored in the index, which should be
        precomposed, that may need to be compared with the names read from
        readdir().
      
      NFS mounted from Linux is fully transparent and does not suffer from
      the above.
      
      As Mac OS X treats precomposed and decomposed file names as equal,
      we can
      
       - wrap readdir() on Mac OS X to return the precomposed form, and
      
       - normalize decomposed form given from the command line also to the
         precomposed form,
      
      to ensure that all pathnames used in Git are always in the
      precomposed form.  This behaviour can be requested by setting
      "core.precomposedunicode" configuration variable to true.
      
      The code in compat/precomposed_utf8.c implements basically 4 new
      functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
      precomposed_utf8_closedir() and precompose_argv().  The first three
      are to wrap opendir(3), readdir(3), and closedir(3) functions.
      
      The argv[] conversion allows to use the TAB filename completion done
      by the shell on command line.  It tolerates other tools which use
      readdir() to feed decomposed file names into git.
      
      When creating a new git repository with "git init" or "git clone",
      "core.precomposedunicode" will be set "false".
      
      The user needs to activate this feature manually.  She typically
      sets core.precomposedunicode to "true" on HFS and VFAT, or file
      systems mounted via SAMBA.
      Helped-by: default avatarJunio C Hamano <[email protected]>
      Signed-off-by: default avatarTorsten Bögershausen <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      76759c7d
  19. 08 May, 2012 1 commit
  20. 05 Mar, 2012 1 commit
    • René Scharfe's avatar
      parse-options: typo check for unknown switches · 38916c5b
      René Scharfe authored
      The user specifies a long option but forgets to type the second
      leading dash, we currently detect and report that fact if its first
      letter is a valid short option. This is done for safety, to avoid
      ambiguity between short options (and their arguments) and a long
      option with a missing dash.
      
      This diagnostic message is also helpful for long options whose first
      letter is not a valid short option, however. Print it in that case,
      too, as a courtesy.
      Signed-off-by: default avatarRene Scharfe <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      38916c5b
  21. 28 Feb, 2012 1 commit
  22. 26 Feb, 2012 1 commit
    • René Scharfe's avatar
      parse-options: allow positivation of options starting, with no- · 0f1930c5
      René Scharfe authored
      Long options can be negated by adding no- right after the leading
      two dashes. This is useful e.g. to override options set by aliases.
      
      For options that are defined to start with no- already, this looks
      a bit funny. Allow such options to also be negated by removing the
      prefix.
      
      The following thirteen options are affected:
      
      	apply          --no-add
      	bisect--helper --no-checkout
      	checkout-index --no-create
      	clone          --no-checkout --no-hardlinks
      	commit         --no-verify   --no-post-rewrite
      	format-patch   --no-binary
      	hash-object    --no-filters
      	read-tree      --no-sparse-checkout
      	revert         --no-commit
      	show-branch    --no-name
      	update-ref     --no-deref
      
      The following five are NOT affected because they are defined with
      PARSE_OPT_NONEG or the non-negated version is defined as well:
      
      	branch       --no-merged
      	format-patch --no-stat             --no-numbered
      	update-index --no-assume-unchanged --no-skip-worktree
      Signed-off-by: default avatarRene Scharfe <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0f1930c5
  23. 28 Sep, 2011 1 commit
    • Junio C Hamano's avatar
      parse-options: deprecate OPT_BOOLEAN · b04ba2bb
      Junio C Hamano authored
      It is natural to expect that an option defined with OPT_BOOLEAN() could be
      used in this way:
      
      	int option = -1; /* unspecified */
      
      	struct option options[] = {
      		OPT_BOOLEAN(0, "option", &option, "set option"),
                      OPT_END()
      	};
      	parse_options(ac, av, prefix, options, usage, 0);
      
              if (option < 0)
              	... do the default thing ...
      	else if (!option)
      		... --no-option was given ...
      	else
      		... --option was given ...
      
      to easily tell three cases apart:
      
       - There is no mention of the `--option` on the command line;
       - The variable is positively set with `--option`; or
       - The variable is explicitly negated with `--no-option`.
      
      Unfortunately, this is not the case. OPT_BOOLEAN() increments the variable
      every time `--option` is given, and resets it to zero when `--no-option`
      is given.
      
      As a first step to remedy this, introduce a true boolean OPT_BOOL(), and
      rename OPT_BOOLEAN() to OPT_COUNTUP(). To help transitioning, OPT_BOOLEAN
      and OPTION_BOOLEAN are defined as deprecated synonyms to OPT_COUNTUP and
      OPTION_COUNTUP respectively.
      
      This is what db7244bd (parse-options new features., 2007-11-07) from four
      years ago started by marking OPTION_BOOLEAN as "INCR would have been a
      better name".
      
      Some existing users do depend on the count-up semantics; for example,
      users of OPT__VERBOSE() could use it to raise the verbosity level with
      repeated use of `-v` on the command line, but they probably should be
      rewritten to use OPT__VERBOSITY() instead these days.  I suspect that some
      users of OPT__FORCE() may also use it to implement different level of
      forcibleness but I didn't check.
      
      On top of this patch, here are the remaining clean-up tasks that other
      people can help:
      
       - Look at each hit in "git grep -e OPT_BOOLEAN"; trace all uses of the
         value that is set to the underlying variable, and if it can proven that
         the variable is only used as a boolean, replace it with OPT_BOOL(). If
         the caller does depend on the count-up semantics, replace it with
         OPT_COUNTUP() instead.
      
       - Same for OPTION_BOOLEAN; replace it with OPTION_SET_INT and arrange to
         set 1 to the variable for a true boolean, and otherwise replace it with
         OPTION_COUNTUP.
      
       - Look at each hit in "git grep -e OPT__VERBOSE -e OPT__QUIET" and see if
         they can be replaced with OPT__VERBOSITY().
      
      I'll follow this message up with a separate patch as an example.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      b04ba2bb
  24. 18 Aug, 2011 1 commit
  25. 11 Aug, 2011 2 commits
    • Dmitry Ivankov's avatar
      Reduce parse-options.o dependencies · 06876284
      Dmitry Ivankov authored
      Currently parse-options.o pulls quite a big bunch of dependencies.
      his complicates it's usage in contrib/ because it pulls external
      dependencies and it also increases executables size.
      
      Split off less generic and more internal to git part of
      parse-options.c to parse-options-cb.c.
      
      Move prefix_filename function from setup.c to abspath.c. abspath.o
      and wrapper.o pull each other, so it's unlikely to increase the
      dependencies. It was a dependency of parse-options.o that pulled
      many others.
      
      Now parse-options.o pulls just abspath.o, ctype.o, strbuf.o, usage.o,
      wrapper.o, libc directly and strlcpy.o indirectly.
      Signed-off-by: default avatarDmitry Ivankov <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      06876284
    • Dmitry Ivankov's avatar
      parse-options: export opterr, optbug · 1f275b7c
      Dmitry Ivankov authored
      opterror and optbug functions are used by some of parsing routines
      in parse-options.c to report errors and bugs respectively.
      
      Export these functions to allow more custom parsing routines to use
      them in a uniform way.
      Signed-off-by: default avatarDmitry Ivankov <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1f275b7c
  26. 22 Jun, 2011 1 commit
  27. 22 Mar, 2011 1 commit
    • Stephen Boyd's avatar
      Fix sparse warnings · c2e86add
      Stephen Boyd authored
      Fix warnings from 'make check'.
      
       - These files don't include 'builtin.h' causing sparse to complain that
         cmd_* isn't declared:
      
         builtin/clone.c:364, builtin/fetch-pack.c:797,
         builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78,
         builtin/merge-index.c:69, builtin/merge-recursive.c:22
         builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426
         builtin/notes.c:822, builtin/pack-redundant.c:596,
         builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149,
         builtin/remote.c:1512, builtin/remote-ext.c:240,
         builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384,
         builtin/unpack-file.c:25, builtin/var.c:75
      
       - These files have symbols which should be marked static since they're
         only file scope:
      
         submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13,
         submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79,
         unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123,
         url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48
      
       - These files redeclare symbols to be different types:
      
         builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571,
         usage.c:49, usage.c:58, usage.c:63, usage.c:72
      
       - These files use a literal integer 0 when they really should use a NULL
         pointer:
      
         daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362
      
      While we're in the area, clean up some unused #includes in builtin files
      (mostly exec_cmd.h).
      Signed-off-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c2e86add
  28. 07 Dec, 2010 7 commits
    • Jonathan Nieder's avatar
      parse-options: make resuming easier after PARSE_OPT_STOP_AT_NON_OPTION · 979240fe
      Jonathan Nieder authored
      Introduce a PARSE_OPT_NON_OPTION state, so parse_option_step()
      callers can easily distinguish between non-options and other
      reasons for option parsing termination (like "--").
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      979240fe
    • Jonathan Nieder's avatar
      parse-options: allow git commands to invent new option types · b0b3a8b6
      Jonathan Nieder authored
      parse-options provides a variety of option behaviors, including
      OPTION_CALLBACK, which should take care of just about any sane
      behavior.  All supported behaviors obey the following constraint:
      
       A --foo option can only accept (and base its behavior on)
       one argument, which would be the following command-line
       argument in the "unsticked" form.
      
      Alas, some existing git commands have options that do not obey that
      constraint.  For example, update-index --cacheinfo takes three
      arguments, and update-index --resolve takes all later parameters as
      arguments.
      
      Introduces an OPTION_LOWLEVEL_CALLBACK backdoor to parse-options so
      such option types can be supported without tempting inventors of other
      commands through mention in the public API.  Commands can set the
      callback field to a function accepting three arguments: the option
      parsing context, the option itself, and a flag indicating whether the
      the option was negated.  When the option is encountered, that function
      is called to take over from get_value().  The return value should be
      zero for success, -1 for usage errors.
      
      Thanks to Stephen Boyd for API guidance.
      Improved-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      b0b3a8b6
    • Jonathan Nieder's avatar
      parse-options: never suppress arghelp if LITERAL_ARGHELP is set · b57c68a6
      Jonathan Nieder authored
      The PARSE_OPT_LITERAL_ARGHELP flag allows a program to override the
      standard "<argument> for mandatory, [argument] for optional" markup in
      its help message.  Extend it to override the usual "no text for
      disallowed", too (for the PARSE_OPT_NOARG | PARSE_OPT_LITERAL_ARGHELP
      case, which was previously meaningless), to be more intuitive.
      
      The motivation is to allow update-index to correctly advertise
      
      	--cacheinfo <mode> <object> <path>
      	                      add the specified entry to the index
      
      while abusing PARSE_OPT_NOARG to disallow the "sticked form"
      
      	--cacheinfo=<mode> <object> <path>
      Noticed-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      b57c68a6
    • Stephen Boyd's avatar
      parse-options: do not infer PARSE_OPT_NOARG from option type · c1f4ec9e
      Stephen Boyd authored
      Simplify the "takes no value" error path by relying on PARSE_OPT_NOARG
      being set correctly.  That is:
      
       - if the PARSE_OPT_NOARG flag is set, reject --opt=value
         regardless of the option type;
       - if the PARSE_OPT_NOARG flag is unset, accept --opt=value
         regardless of the option type.
      
      This way, the accepted usage more closely matches the usage advertised
      with --help-all.
      
      No functional change intended, since the NOARG flag is only used
      with "boolean-only" option types in existing parse_options callers.
      Signed-off-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <g[email protected]>
      c1f4ec9e
    • Jonathan Nieder's avatar
      parse-options: sanity check PARSE_OPT_NOARG flag · 5c400ed2
      Jonathan Nieder authored
      Some option types cannot use an argument --- boolean options that
      would set a bit or flag or increment a counter, for example.  If
      configured in the flag word to accept an argument anyway, the result
      is an argument that is advertised in "program -h" output only to be
      rejected by parse-options::get_value.
      
      Luckily all current users of these option types use PARSE_OPT_NOARG
      and do not use PARSE_OPT_OPTARG.  Add a check to ensure that that
      remains true.  The check is run once for each invocation of
      parse_option_start().
      Improved-by: default avatarStephen Boyd <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5c400ed2
    • Jonathan Nieder's avatar
      parse-options: move NODASH sanity checks to parse_options_check · a02dd4ff
      Jonathan Nieder authored
      A dashless switch (like '(' passed to 'git grep') cannot be negated,
      cannot be attached to an argument, and cannot have a long form.
      Currently parse-options runs the related sanity checks when the
      dashless option is used; better to always check them at the start of
      option parsing, so mistakes can be caught more quickly.
      
      The error message at the new call site is less specific about the
      nature of the error, for simplicity.  On the other hand, it prints
      which switch was problematic.  Before:
      
      	fatal: BUG: dashless options can't be long
      
      After:
      
      	error: BUG: switch '(' uses feature not supported for dashless options
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a02dd4ff
    • Jonathan Nieder's avatar
      parse-options: clearer reporting of API misuse · 1e5ce570
      Jonathan Nieder authored
      The PARSE_OPT_LASTARG_DEFAULT flag is meant for options like
      --contains that (1) traditionally had a mandatory argument and
      (2) have some better behavior to use when appearing in the final
      position.  It makes no sense to combine this with OPTARG, so ever
      since v1.6.4-rc0~71 (parse-options: add parse_options_check to
      validate option specs, 2009-07-09) this mistake is flagged with
      
      	error: `--option` uses incompatible flags LASTARG_DEFAULT and OPTARG
      
      and an exit status representing an error in commandline usage.
      
      Unfortunately that which might confuse scripters calling such an
      erroneous program into thinking the _script_ contains an error.
      Clarify that it is an internal error by dying with a message beginning
      "error: BUG: ..." and status 128.
      
      While at it, clean up parse_options_check to prepare for more checks.
      
      Long term, it would be nicer to make such checks happen at compile
      time.
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1e5ce570