1. 24 Apr, 2018 2 commits
    • Martin Ågren's avatar
      walker: drop fields of `struct walker` which are always 1 · 0b6b3429
      Martin Ågren authored
      After the previous commit, both users of `struct walker` set `get_tree`,
      `get_history` and `get_all` to 1. Drop those fields and simplify the
      walker implementation accordingly.
      
      Let's hope that any out-of-tree users will not mind this change. They
      should notice that the compilation fails as they try to set these
      fields. (If they do not set them, note that `get_http_walker()` leaves
      them undefined, so the behavior will have been undefined all the time.)
      Signed-off-by: 's avatarMartin Ågren <martin.agren@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      0b6b3429
    • Martin Ågren's avatar
      http-fetch: make `-a` standard behaviour · 2e85a0c8
      Martin Ågren authored
      This is a follow-up to a6c786fc (Mark http-fetch without -a as
      deprecated, 2011-08-23). For more than six years, we have been warning
      when `-a` is not provided, and the documentation has been saying that
      `-a` will become the default.
      
      It is a bit unclear what "default" means here. There is no such thing as
      `http-fetch --no-a`. But according to my searches, no-one has been
      asking on the mailing list how they should silence the warning and
      prepare for overriding the flipped default. So let's assume that
      everybody is happy with `-a`. They should be, since not using it may
      break the repo in such a way that Git itself is unable to fix it.
      
      Always behave as if `-a` was given. Since `-a` implies `-c` (get commit
      objects) and `-t` (get trees), all three options are now unnecessary.
      Document all of these as historical artefacts that have no effect.
      
      Leave no-op code for handling these options in http-fetch.c. The
      options-handling is currently rather loose. If someone tightens it, we
      will not want these ignored options to accidentally turn into hard
      errors.
      
      Since `-a` was the only safe and sane usage and we have been pushing
      people towards it for a long time, refrain from warning when it is used
      "unnecessarily" now. Similarly, do not add anything scary-looking to the
      man-page about how it will be removed in the future. We can always do so
      later. (It is not like we are in desperate need of freeing up
      one-letter arguments.)
      Signed-off-by: 's avatarMartin Ågren <martin.agren@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      2e85a0c8
  2. 11 Apr, 2018 1 commit
  3. 15 Jun, 2017 1 commit
  4. 01 Jul, 2016 3 commits
    • Jeff King's avatar
      common-main: call git_setup_gettext() · 5ce5f5fa
      Jeff King authored
      This should be part of every program, as otherwise users do
      not get translated error messages. However, some external
      commands forgot to do so (e.g., git-credential-store). This
      fixes them, and eliminates the repeated code in programs
      that did remember to use it.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      5ce5f5fa
    • Jeff King's avatar
      common-main: call git_extract_argv0_path() · 650c4492
      Jeff King authored
      Every program which links against libgit.a must call this
      function, or risk hitting an assert() in system_path() that
      checks whether we have configured argv0_path (though only
      when RUNTIME_PREFIX is defined, so essentially only on
      Windows).
      
      Looking at the diff, you can see that putting it into the
      common main() saves us having to do it individually in each
      of the external commands. But what you can't see are the
      cases where we _should_ have been doing so, but weren't
      (e.g., git-credential-store, and all of the t/helper test
      programs).
      
      This has been an accident-waiting-to-happen for a long time,
      but wasn't triggered until recently because it involves one
      of those programs actually calling system_path(). That
      happened with git-credential-store in v2.8.0 with ae5f6776
      (lazily load core.sharedrepository, 2016-03-11). The
      program:
      
        - takes a lock file, which...
      
        - opens a tempfile, which...
      
        - calls adjust_shared_perm to fix permissions, which...
      
        - lazy-loads the config (as of ae5f6776), which...
      
        - calls system_path() to find the location of
          /etc/gitconfig
      
      On systems with RUNTIME_PREFIX, this means credential-store
      reliably hits that assert() and cannot be used.
      
      We never noticed in the test suite, because we set
      GIT_CONFIG_NOSYSTEM there, which skips the system_path()
      lookup entirely.  But if we were to tweak git_config() to
      find /etc/gitconfig even when we aren't going to open it,
      then the test suite shows multiple failures (for
      credential-store, and for some other test helpers). I didn't
      include that tweak here because it's way too specific to
      this particular call to be worth carrying around what is
      essentially dead code.
      
      The implementation is fairly straightforward, with one
      exception: there is exactly one caller (git.c) that actually
      cares about the result of the function, and not the
      side-effect of setting up argv0_path. We can accommodate
      that by simply replacing the value of argv[0] in the array
      we hand down to cmd_main().
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      650c4492
    • Jeff King's avatar
      add an extra level of indirection to main() · 3f2e2297
      Jeff King authored
      There are certain startup tasks that we expect every git
      process to do. In some cases this is just to improve the
      quality of the program (e.g., setting up gettext()). In
      others it is a requirement for using certain functions in
      libgit.a (e.g., system_path() expects that you have called
      git_extract_argv0_path()).
      
      Most commands are builtins and are covered by the git.c
      version of main(). However, there are still a few external
      commands that use their own main(). Each of these has to
      remember to include the correct startup sequence, and we are
      not always consistent.
      
      Rather than just fix the inconsistencies, let's make this
      harder to get wrong by providing a common main() that can
      run this standard startup.
      
      We basically have two options to do this:
      
       - the compat/mingw.h file already does something like this by
         adding a #define that replaces the definition of main with a
         wrapper that calls mingw_startup().
      
         The upside is that the code in each program doesn't need
         to be changed at all; it's rewritten on the fly by the
         preprocessor.
      
         The downside is that it may make debugging of the startup
         sequence a bit more confusing, as the preprocessor is
         quietly inserting new code.
      
       - the builtin functions are all of the form cmd_foo(),
         and git.c's main() calls them.
      
         This is much more explicit, which may make things more
         obvious to somebody reading the code. It's also more
         flexible (because of course we have to figure out _which_
         cmd_foo() to call).
      
         The downside is that each of the builtins must define
         cmd_foo(), instead of just main().
      
      This patch chooses the latter option, preferring the more
      explicit approach, even though it is more invasive. We
      introduce a new file common-main.c, with the "real" main. It
      expects to call cmd_main() from whatever other objects it is
      linked against.
      
      We link common-main.o against anything that links against
      libgit.a, since we know that such programs will need to do
      this setup. Note that common-main.o can't actually go inside
      libgit.a, as the linker would not pick up its main()
      function automatically (it has no callers).
      
      The rest of the patch is just adjusting all of the various
      external programs (mostly in t/helper) to use cmd_main().
      I've provided a global declaration for cmd_main(), which
      means that all of the programs also need to match its
      signature. In particular, many functions need to switch to
      "const char **" instead of "char **" for argv. This effect
      ripples out to a few other variables and functions, as well.
      
      This makes the patch even more invasive, but the end result
      is much better. We should be treating argv strings as const
      anyway, and now all programs conform to the same signature
      (which also matches the way builtins are defined).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      3f2e2297
  5. 14 Dec, 2011 1 commit
    • Jeff King's avatar
      http-push: enable "proactive auth" · a4ddbc33
      Jeff King authored
      Before commit 986bbc08, git was proactive about asking for
      http passwords. It assumed that if you had a username in
      your URL, you would also want a password, and asked for it
      before making any http requests.
      
      However, this could interfere with the use of .netrc (see
      986bbc08 for details). And it was also unnecessary, since
      the http fetching code had learned to recognize an HTTP 401
      and prompt the user then. Furthermore, the proactive prompt
      could interfere with the usage of .netrc (see 986bbc08 for
      details).
      
      Unfortunately, the http push-over-DAV code never learned to
      recognize HTTP 401, and so was broken by this change. This
      patch does a quick fix of re-enabling the "proactive auth"
      strategy only for http-push, leaving the dumb http fetch and
      smart-http as-is.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      a4ddbc33
  6. 06 Dec, 2011 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      i18n: add infrastructure for translating Git with gettext · 5e9637c6
      Ævar Arnfjörð Bjarmason authored
      Change the skeleton implementation of i18n in Git to one that can show
      localized strings to users for our C, Shell and Perl programs using
      either GNU libintl or the Solaris gettext implementation.
      
      This new internationalization support is enabled by default. If
      gettext isn't available, or if Git is compiled with
      NO_GETTEXT=YesPlease, Git falls back on its current behavior of
      showing interface messages in English. When using the autoconf script
      we'll auto-detect if the gettext libraries are installed and act
      appropriately.
      
      This change is somewhat large because as well as adding a C, Shell and
      Perl i18n interface we're adding a lot of tests for them, and for
      those tests to work we need a skeleton PO file to actually test
      translations. A minimal Icelandic translation is included for this
      purpose. Icelandic includes multi-byte characters which makes it easy
      to test various edge cases, and it's a language I happen to
      understand.
      
      The rest of the commit message goes into detail about various
      sub-parts of this commit.
      
      = Installation
      
      Gettext .mo files will be installed and looked for in the standard
      $(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
      override that, but that's only intended to be used to test Git itself.
      
      = Perl
      
      Perl code that's to be localized should use the new Git::I18n
      module. It imports a __ function into the caller's package by default.
      
      Instead of using the high level Locale::TextDomain interface I've
      opted to use the low-level (equivalent to the C interface)
      Locale::Messages module, which Locale::TextDomain itself uses.
      
      Locale::TextDomain does a lot of redundant work we don't need, and
      some of it would potentially introduce bugs. It tries to set the
      $TEXTDOMAIN based on package of the caller, and has its own
      hardcoded paths where it'll search for messages.
      
      I found it easier just to completely avoid it rather than try to
      circumvent its behavior. In any case, this is an issue wholly
      internal Git::I18N. Its guts can be changed later if that's deemed
      necessary.
      
      See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
      a further elaboration on this topic.
      
      = Shell
      
      Shell code that's to be localized should use the git-sh-i18n
      library. It's basically just a wrapper for the system's gettext.sh.
      
      If gettext.sh isn't available we'll fall back on gettext(1) if it's
      available. The latter is available without the former on Solaris,
      which has its own non-GNU gettext implementation. We also need to
      emulate eval_gettext() there.
      
      If neither are present we'll use a dumb printf(1) fall-through
      wrapper.
      
      = About libcharset.h and langinfo.h
      
      We use libcharset to query the character set of the current locale if
      it's available. I.e. we'll use it instead of nl_langinfo if
      HAVE_LIBCHARSET_H is set.
      
      The GNU gettext manual recommends using langinfo.h's
      nl_langinfo(CODESET) to acquire the current character set, but on
      systems that have libcharset.h's locale_charset() using the latter is
      either saner, or the only option on those systems.
      
      GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
      but MinGW and some others need to use libcharset.h's locale_charset()
      instead.
      
      =Credits
      
      This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
      did the initial Makefile / C work, and a lot of comments from the Git
      mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
      Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
      others.
      
      [jc: squashed a small Makefile fix from Ramsay]
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: 's avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      5e9637c6
  7. 16 Oct, 2011 1 commit
    • Jeff King's avatar
      http_init: accept separate URL parameter · deba4937
      Jeff King authored
      The http_init function takes a "struct remote". Part of its
      initialization procedure is to look at the remote's url and
      grab some auth-related parameters. However, using the url
      included in the remote is:
      
        - wrong; the remote-curl helper may have a separate,
          unrelated URL (e.g., from remote.*.pushurl). Looking at
          the remote's configured url is incorrect.
      
        - incomplete; http-fetch doesn't have a remote, so passes
          NULL. So http_init never gets to see the URL we are
          actually going to use.
      
        - cumbersome; http-push has a similar problem to
          http-fetch, but actually builds a fake remote just to
          pass in the URL.
      
      Instead, let's just add a separate URL parameter to
      http_init, and all three callsites can pass in the
      appropriate information.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      deba4937
  8. 24 Aug, 2011 1 commit
  9. 03 Apr, 2011 1 commit
  10. 26 Nov, 2010 1 commit
    • Ray's avatar
      http-fetch: rework url handling · 6f5185bd
      Ray authored
      Do away with a second url variable, rewritten_url, and make url
      non-const. This is safe because the functions called with url (ie.
      get_http_walker() and walker_fetch()) do not modify it (ie. marked with
      const char *).
      
      Also, replace code that adds a trailing slash with a call to
      str_end_url_with_slash().
      Signed-off-by: Ray's avatarTay Ray Chuan <rctay89@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      6f5185bd
  11. 02 Mar, 2010 1 commit
  12. 10 Nov, 2009 2 commits
  13. 06 Aug, 2009 1 commit
  14. 09 Sep, 2008 2 commits
  15. 14 May, 2008 1 commit
  16. 27 Feb, 2008 1 commit
    • Mike Hommey's avatar
      Set proxy override with http_init() · 9fc6440d
      Mike Hommey authored
      In transport.c, proxy setting (the one from the remote conf) was set through
      curl_easy_setopt() call, while http.c already does the same with the
      http.proxy setting. We now just use this infrastructure instead, and make
      http_init() now take the struct remote as argument so that it can take the
      http_proxy setting from there, and any other property that would be added
      later.
      
      At the same time, we make get_http_walker() take a struct remote argument
      too, and pass it to http_init(), which makes remote defined proxy be used
      for more than get_refs_via_curl().
      
      We leave out http-fetch and http-push, which don't use remotes for the
      moment, purposefully.
      Signed-off-by: 's avatarMike Hommey <mh@glandium.org>
      Acked-by: 's avatarDaniel Barkalow <barkalow@iabervon.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      9fc6440d
  17. 22 Feb, 2008 1 commit
    • Jim Meyering's avatar
      Avoid unnecessary "if-before-free" tests. · 8e0f7003
      Jim Meyering authored
      This change removes all obvious useless if-before-free tests.
      E.g., it replaces code like this:
      
              if (some_expression)
                      free (some_expression);
      
      with the now-equivalent:
      
              free (some_expression);
      
      It is equivalent not just because POSIX has required free(NULL)
      to work for a long time, but simply because it has worked for
      so long that no reasonable porting target fails the test.
      Here's some evidence from nearly 1.5 years ago:
      
          http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
      
      FYI, the change below was prepared by running the following:
      
        git ls-files -z | xargs -0 \
        perl -0x3b -pi -e \
          's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
      
      Note however, that it doesn't handle brace-enclosed blocks like
      "if (x) { free (x); }".  But that's ok, since there were none like
      that in git sources.
      
      Beware: if you do use the above snippet, note that it can
      produce syntactically invalid C code.  That happens when the
      affected "if"-statement has a matching "else".
      E.g., it would transform this
      
        if (x)
          free (x);
        else
          foo ();
      
      into this:
      
        free (x);
        else
          foo ();
      
      There were none of those here, either.
      
      If you're interested in automating detection of the useless
      tests, you might like the useless-if-before-free script in gnulib:
      [it *does* detect brace-enclosed free statements, and has a --name=S
       option to make it detect free-like functions with different names]
      
        http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
      
      Addendum:
        Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
      Signed-off-by: 's avatarJim Meyering <meyering@redhat.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      8e0f7003
  18. 20 Jan, 2008 1 commit
  19. 19 Sep, 2007 1 commit