1. 30 3月, 2020 4 次提交
  2. 15 11月, 2019 1 次提交
  3. 07 11月, 2019 1 次提交
  4. 17 3月, 2018 1 次提交
  5. 06 3月, 2018 1 次提交
    • Æ
      perl Git::LoadCPAN: emit better errors under NO_PERL_CPAN_FALLBACKS · 1aca69c0
      Ævar Arnfjörð Bjarmason 提交于
      Before my 20d2a30f ("Makefile: replace perl/Makefile.PL with simple
      make rules", 2017-12-10) on an OS package that removed the
      private-Error.pm copy we carried around manually removing the OS's
      Error.pm would yield:
      
          $ git add -p
          Can't locate Error.pm in @inc (you may need to install the Error module) [...]
      
      Now, before this change we'll instead emit this more cryptic error:
      
          $ git add -p
          BUG: '/usr/share/perl5/Git/FromCPAN' should be a directory! at /usr/share/perl5/Git/Error.pm line 36.
      
      This is a confusing error. Now if the new NO_PERL_CPAN_FALLBACKS
      option is specified and we can't find the module we'll instead emit:
      
          $ /tmp/git/bin/git add -p
          BUG: The 'Error' module is not here, but NO_PERL_CPAN_FALLBACKS was set!
      
          [...]
      
      Where [...] is the lengthy explanation seen in the change below, which
      explains what the potential breakage is, and how to fix it.
      
      The reason for checking @@NO_PERL_CPAN_FALLBACKS@@] against the empty
      string in Perl is as opposed to checking for a boolean value is that
      that's (as far as I can tell) make's idea of a string that's set, and
      e.g. NO_PERL_CPAN_FALLBACKS=0 is enough to set NO_PERL_CPAN_FALLBACKS.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1aca69c0
  6. 12 12月, 2017 1 次提交
    • Æ
      Makefile: replace perl/Makefile.PL with simple make rules · 20d2a30f
      Ævar Arnfjörð Bjarmason 提交于
      Replace the perl/Makefile.PL and the fallback perl/Makefile used under
      NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily
      inspired by how the i18n infrastructure's build process works[1].
      
      The reason for having the Makefile.PL in the first place is that it
      was initially[2] building a perl C binding to interface with libgit,
      this functionality, that was removed[3] before Git.pm ever made it to
      the master branch.
      
      We've since since started maintaining a fallback perl/Makefile, as
      MakeMaker wouldn't work on some platforms[4]. That's just the tip of
      the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to
      detect whether we need to regenerate the perl/perl.mak, which I fixed
      just recently to deal with issues like the perl version changing from
      under us[6].
      
      There is absolutely no reason for why this needs to be so complex
      anymore. All we're getting out of this elaborate Rube Goldberg machine
      was copying perl/* to perl/blib/* as we do a string-replacement on
      the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as
      pod2man-ing Git.pm & friends.
      
      So replace the whole thing with something that's pretty much a copy of
      how we generate po/build/**.mo from po/*.po, just with a small sed(1)
      command instead of msgfmt. As that's being done rename the files
      from *.pm to *.pmc just to indicate that they're generated (see
      "perldoc -f require").
      
      While I'm at it, change the fallback for Error.pm from being something
      where we'll ship our own Error.pm if one doesn't exist at build time
      to one where we just use a Git::Error wrapper that'll always prefer
      the system-wide Error.pm, only falling back to our own copy if it
      really doesn't exist at runtime. It's now shipped as
      Git::FromCPAN::Error, making it easy to add other modules to
      Git::FromCPAN::* in the future if that's needed.
      
      Functional changes:
      
       * This will not always install into perl's idea of its global
         "installsitelib". This only potentially matters for packagers that
         need to expose Git.pm for non-git use, and as explained in the
         INSTALL file there's a trivial workaround.
      
       * The scripts themselves will 'use lib' the target directory, but if
         INSTLIBDIR is set it overrides it. It doesn't have to be this way,
         it could be set in addition to INSTLIBDIR, but my reading of [7] is
         that this is the desired behavior.
      
       * We don't build man pages for all of the perl modules as we used to,
         only Git(3pm). As discussed on-list[8] that we were building
         installed manpages for purely internal APIs like Git::I18N or
         private-Error.pm was always a bug anyway, and all the Git::SVN::*
         ones say they're internal APIs.
      
         There are apparently external users of Git.pm, but I don't expect
         there to be any of the others.
      
         As a side-effect of these general changes the perl documentation
         now only installed by install-{doc,man}, not a mere "install" as
         before.
      
      1. 5e9637c6 ("i18n: add infrastructure for translating Git with
         gettext", 2011-11-18)
      
      2. b1edc53d ("Introduce Git.pm (v4)", 2006-06-24)
      
      3. 18b0fc1c ("Git.pm: Kill Git.xs for now", 2006-09-23)
      
      4. f848718a ("Make perl/ build procedure ActiveState friendly.",
         2006-12-04)
      
      5. ee9be067 ("perl: detect new files in MakeMaker builds",
         2012-07-27)
      
      6. c59c4939 ("perl: regenerate perl.mak if perl -V changes",
         2017-03-29)
      
      7. 0386dd37 ("Makefile: add PERLLIB_EXTRA variable that adds to
         default perl path", 2013-11-15)
      
      8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile:
         replace perl/Makefile.PL with simple make rules"
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      20d2a30f
  7. 11 11月, 2014 1 次提交
    • B
      git-imap-send: use libcurl for implementation · 1e16b255
      Bernhard Reiter 提交于
      Use libcurl's high-level API functions to implement git-imap-send
      instead of the previous low-level OpenSSL-based functions.
      
      Since version 7.30.0, libcurl's API has been able to communicate with
      IMAP servers. Using those high-level functions instead of the current
      ones would reduce imap-send.c by some 1200 lines of code. For now,
      the old ones are wrapped in #ifdefs, and the new functions are enabled
      by make if curl's version is >= 7.34.0, from which version on curl's
      CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been
      available. The low-level functions will still be used for tunneling
      into the server for now.
      
      As I don't have access to that many IMAP servers, I haven't been able to
      test the new code with a wide variety of parameter combinations. I did
      test both secure and insecure (imaps:// and imap://) connections and
      values of "PLAIN" and "LOGIN" for the authMethod.
      
      In order to suppress a sparse warning about "using sizeof on a
      function", we use the same solution used in commit 9371322a
      ("sparse: suppress some "using sizeof on a function" warnings",
      06-10-2013) which solved exactly this problem for the other commands
      using libcurl.
      Helped-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: NBernhard Reiter <ockham@raz.or.at>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1e16b255
  8. 09 7月, 2014 1 次提交
    • A
      Fix profile feedback with -jN and add profile-fast · 066dd263
      Andi Kleen 提交于
      Profile feedback always failed for me with -jN. The problem
      was that there was no implicit ordering between the profile generate
      stage and the profile use stage. So some objects in the later stage
      would be linked with profile generate objects, and fail due
      to the missing -lgcov.
      
      This adds a new profile target that implicitely enforces the
      correct ordering by using submakes. Plus a profile-install target
      to also install. This is also nicer to type that PROFILE=...
      
      Plus I always run the performance test suite now for the full
      profile run.
      
      In addition I also added a profile-fast / profile-fast-install
      target the only runs the performance test suite instead of the
      whole test suite. This significantly speeds up the profile build,
      which was totally dominated by test suite run time. However
      it may have less coverage of course.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      066dd263
  9. 12 4月, 2013 1 次提交
  10. 31 1月, 2013 1 次提交
  11. 27 1月, 2013 2 次提交
  12. 31 5月, 2012 1 次提交
  13. 10 4月, 2012 1 次提交
  14. 06 2月, 2012 1 次提交
    • T
      Fix build problems related to profile-directed optimization · f2d713fc
      Theodore Ts'o 提交于
      There was a number of problems I ran into when trying the
      profile-directed optimizations added by Andi Kleen in git commit
      7ddc2710.  (This was using gcc 4.4 found on many enterprise
      distros.)
      
      1) The -fprofile-generate and -fprofile-use commands are incompatible
      with ccache; the code ends up looking in the wrong place for the gcda
      files based on the ccache object names.
      
      2) If the makefile notices that CFLAGS are different, it will rebuild
      all of the binaries.  Hence the recipe originally specified by the
      INSTALL file ("make profile-all" followed by "make install") doesn't
      work.  It will appear to work, but the binaries will end up getting
      built with no optimization.
      
      This patch fixes this by using an explicit set of options passed via
      the PROFILE variable then using this to directly manipulate CFLAGS and
      EXTLIBS.
      
      The developer can run "make PROFILE=BUILD all ; sudo make
      PROFILE=BUILD install" automatically run a two-pass build with the
      test suite run in between as the sample workload for the purpose of
      recording profiling information to do the profile-directed
      optimization.
      
      Alternatively, the profiling version of binaries can be built using:
      
      	make PROFILE=GEN PROFILE_DIR=/var/cache/profile all
      	make PROFILE=GEN install
      
      and then after git has been used for a while, the optimized version of
      the binary can be built as follows:
      
      	make PROFILE=USE PROFILE_DIR=/var/cache/profile all
      	make PROFILE=USE install
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: Andi Kleen <ak@linux.intel.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f2d713fc
  15. 27 1月, 2012 1 次提交
  16. 06 12月, 2011 1 次提交
    • Æ
      i18n: add infrastructure for translating Git with gettext · 5e9637c6
      Ævar Arnfjörð Bjarmason 提交于
      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: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5e9637c6
  17. 09 11月, 2011 1 次提交
  18. 21 6月, 2011 1 次提交
  19. 25 11月, 2010 1 次提交
    • J
      docs: default to more modern toolset · 79c461d5
      Jeff King 提交于
      When the ASCIIDOC8 and ASCIIDOC_NO_ROFF knobs were built,
      many people were still on asciidoc 7 and using older
      versions of docbook-xsl. These days, even the almost
      2-year-old Debian stable needs these knobs turned.
      
      So let's turn them by default. The new knobs ASCIIDOC7 and
      ASCIIDOC_ROFF can be used to get the old behavior if people
      are on older systems.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      79c461d5
  20. 28 9月, 2010 1 次提交
    • Æ
      perl: bump the required Perl version to 5.8 from 5.6.[21] · d48b2841
      Ævar Arnfjörð Bjarmason 提交于
      Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already
      used the three-arg form of open() which was introduced in 5.6.1, but
      t/t9700/test.pl explicitly depended on 5.6.2.
      
      However git-add--interactive.pl has been failing on the 5.6 line since
      it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open
      syntax:
      
          sub run_cmd_pipe {
                 my $fh = undef;
                 open($fh, '-|', @_) or die;
                 return <$fh>;
          }
      
      Which when executed dies on "Can't use an undefined value as
      filehandle reference". Several of our tests also fail on 5.6 (even
      more when compiled with NO_PERL_MAKEMAKER=1):
      
          t2016-checkout-patch.sh
          t3904-stash-patch.sh
          t3701-add-interactive.sh
          t7105-reset-patch.sh
          t7501-commit.sh
          t9700-perl-git.sh
      
      Our code is bitrotting on 5.6 with no-one interested in fixing it, and
      pinning us to such an ancient release of Perl is keeping us from using
      useful features introduced in the 5.8 release.
      
      The 5.6 series is now over 10 years old, and the 5.6.2 maintenance
      release almost 7. 5.8 on the other hand is more than 8 years old.
      
      All the modern Unix-like operating systems have now upgraded to it or
      a later version, and 5.8 packages are available for old IRIX, AIX
      Solaris and Tru64 systems.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Acked-by: NTor Arntsen <tor@spacetec.no>
      Acked-by: NRandal L. Schwartz <merlyn@stonehenge.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d48b2841
  21. 26 7月, 2010 1 次提交
  22. 14 2月, 2010 1 次提交
  23. 04 12月, 2009 1 次提交
  24. 05 11月, 2009 1 次提交
  25. 11 9月, 2009 2 次提交
  26. 09 9月, 2009 1 次提交
  27. 11 12月, 2008 1 次提交
  28. 03 11月, 2008 1 次提交
  29. 11 9月, 2008 2 次提交
  30. 05 8月, 2008 1 次提交
  31. 09 7月, 2008 1 次提交
  32. 06 7月, 2008 1 次提交
  33. 16 6月, 2008 2 次提交