1. 15 Jan, 2016 1 commit
    • Junio C Hamano's avatar
      strbuf: introduce strbuf_getline_{lf,nul}() · 8f309aeb
      Junio C Hamano authored
      The strbuf_getline() interface allows a byte other than LF or NUL as
      the line terminator, but this is only because I wrote these
      codepaths anticipating that there might be a value other than NUL
      and LF that could be useful when I introduced line_termination long
      time ago.  No useful caller that uses other value has emerged.
      
      By now, it is clear that the interface is overly broad without a
      good reason.  Many codepaths have hardcoded preference to read
      either LF terminated or NUL terminated records from their input, and
      then call strbuf_getline() with LF or NUL as the third parameter.
      
      This step introduces two thin wrappers around strbuf_getline(),
      namely, strbuf_getline_lf() and strbuf_getline_nul(), and
      mechanically rewrites these call sites to call either one of
      them.  The changes contained in this patch are:
      
       * introduction of these two functions in strbuf.[ch]
      
       * mechanical conversion of all callers to strbuf_getline() with
         either '\n' or '\0' as the third parameter to instead call the
         respective thin wrapper.
      
      After this step, output from "git grep 'strbuf_getline('" would
      become a lot smaller.  An interim goal of this series is to make
      this an empty set, so that we can have strbuf_getline_crlf() take
      over the shorter name strbuf_getline().
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8f309aeb
  2. 19 Jun, 2014 1 commit
  3. 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 <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59556548
  4. 17 Jul, 2013 1 commit
  5. 10 Mar, 2013 1 commit
    • Jonathan Nieder's avatar
      shell: new no-interactive-login command to print a custom message · 35297089
      Jonathan Nieder authored
      If I disable git-shell's interactive mode by removing the
      ~/git-shell-commands directory, attempts to ssh in to the service
      produce a message intended for the administrator:
      
      	$ ssh git@myserver
      	fatal: Interactive git shell is not enabled.
      	hint: ~/git-shell-commands should exist and have read and execute access.
      	$
      
      That is helpful for the new admin who is wondering "What? Why isn't
      the git-shell I just set up working?", but once the site setup is
      complete, it would be better to give the user a friendly hint that she
      is on the right track, like GitHub does.
      
      	Hi <username>! You've successfully authenticated, but
      	GitHub does not provide shell access.
      
      An appropriate greeting might even include more complex dynamic
      information, like gitolite's list of repositories the user has access
      to.  Add support for a ~/git-shell-commands/no-interactive-login
      command that generates an arbitrary greeting.  When the user tries to
      log in:
      
       * If the file ~/git-shell-commands/no-interactive-login exists,
         run no-interactive-login to let the server say what it likes,
         then hang up.
      
       * Otherwise, if ~/git-shell-commands/ is present, start an
         interactive read-eval-print loop.
      
       * Otherwise, print the usual configuration hint and hang up.
      Reported-by: Ethan Reesor's avatarEthan Reesor <firelizzard@gmail.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Improved-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      35297089
  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: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5e9637c6
  7. 05 May, 2011 1 commit
  8. 27 Aug, 2010 1 commit
  9. 24 Aug, 2010 1 commit
  10. 12 Aug, 2010 2 commits
  11. 27 Jun, 2009 1 commit
  12. 11 Apr, 2009 1 commit
  13. 30 Aug, 2008 1 commit
  14. 29 Aug, 2008 1 commit
    • Paolo Bonzini's avatar
      make git-shell paranoid about closed stdin/stdout/stderr · 0cfeed2e
      Paolo Bonzini authored
      It is in general unsafe to start a program with one or more of file
      descriptors 0/1/2 closed.  Karl Chen for example noticed that stat_command
      does this in order to rename a pipe file descriptor to 0:
      
          dup2(from, 0);
          close(from);
      
      ... but if stdin was closed (for example) from == 0, so that
      
          dup2(0, 0);
          close(0);
      
      just ends up closing the pipe.  Another extremely rare but nasty problem
      would occur if an "important" file ends up in file descriptor 2, and is
      corrupted by a call to die().
      
      Fixing this in git was considered to be overkill, so this patch works
      around it only for git-shell.  The fix is simply to open all the "low"
      descriptors to /dev/null in main.
      Signed-off-by: Paolo Bonzini's avatarPaolo Bonzini <bonzini@gnu.org>
      Acked-by: Stephen R. van den Berg's avatarStephen R. van den Berg <srb@cuci.nl>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0cfeed2e
  15. 26 Aug, 2008 1 commit
    • Junio C Hamano's avatar
      Revert "Build-in "git-shell"" · 1e7abc59
      Junio C Hamano authored
      This reverts commit daa0cc9a.
      It was a stupid idea to do this; when run as a log-in shell,
      it is spawned with argv[0] set to "-git-shell", so the usual
      name-based dispatch would not work to begin with.
      1e7abc59
  16. 20 Aug, 2008 2 commits
  17. 26 Jul, 2008 1 commit
  18. 28 Jun, 2008 1 commit
    • Dmitry Potapov's avatar
      shrink git-shell by avoiding redundant dependencies · 5b8e6f85
      Dmitry Potapov authored
      A lot of modules that have nothing to do with git-shell functionality
      were linked in, bloating git-shell more than 8 times.
      
      This patch cuts off redundant dependencies by:
      1. providing stubs for three functions that make no sense for git-shell;
      2. moving quote_path_fully from environment.c to quote.c to make the
         later self sufficient;
      3. moving make_absolute_path into a new separate file.
      
      The following numbers have been received with the default optimization
      settings on master using GCC 4.1.2:
      
      Before:
         text    data     bss     dec     hex filename
       143915    1348   93168  238431   3a35f git-shell
      
      After:
         text    data     bss     dec     hex filename
        17670     788    8232   26690    6842 git-shell
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5b8e6f85
  19. 26 Jun, 2008 1 commit
  20. 24 Jun, 2008 1 commit
  21. 30 Oct, 2007 1 commit
  22. 16 Oct, 2007 1 commit
  23. 21 Feb, 2007 1 commit
    • Junio C Hamano's avatar
      Mechanical conversion to use prefixcmp() · cc44c765
      Junio C Hamano authored
      This mechanically converts strncmp() to use prefixcmp(), but only when
      the parameters match specific patterns, so that they can be verified
      easily.  Leftover from this will be fixed in a separate step, including
      idiotic conversions like
      
          if (!strncmp("foo", arg, 3))
      
        =>
      
          if (!(-prefixcmp(arg, "foo")))
      
      This was done by using this script in px.perl
      
         #!/usr/bin/perl -i.bak -p
         if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
                 s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
         }
         if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
                 s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
         }
      
      and running:
      
         $ git grep -l strncmp -- '*.c' | xargs perl px.perl
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      cc44c765
  24. 05 Mar, 2006 1 commit
    • Junio C Hamano's avatar
      Const tightening. · 9201c707
      Junio C Hamano authored
      Mark Wooding noticed there was a type mismatch warning in git.c; this
      patch does things slightly differently (mostly tightening const) and
      was what I was holding onto, waiting for the setup-revisions change
      to be merged into the master branch.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      9201c707
  25. 14 Jan, 2006 1 commit
    • Michal Ostrowski's avatar
      Exec git programs without using PATH. · 77cb17e9
      Michal Ostrowski authored
      The git suite may not be in PATH (and thus programs such as
      git-send-pack could not exec git-rev-list).  Thus there is a need for
      logic that will locate these programs.  Modifying PATH is not
      desirable as it result in behavior differing from the user's
      intentions, as we may end up prepending "/usr/bin" to PATH.
      
      - git C programs will use exec*_git_cmd() APIs to exec sub-commands.
      - exec*_git_cmd() will execute a git program by searching for it in
        the following directories:
      	1. --exec-path (as used by "git")
      	2. The GIT_EXEC_PATH environment variable.
      	3. $(gitexecdir) as set in Makefile (default value $(bindir)).
      - git wrapper will modify PATH as before to enable shell scripts to
        invoke "git-foo" commands.
      
      Ideally, shell scripts should use the git wrapper to become independent
      of PATH, and then modifying PATH will not be necessary.
      
      [jc: with minor updates after a brief review.]
      Signed-off-by: default avatarMichal Ostrowski <mostrows@watson.ibm.com>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      77cb17e9
  26. 26 Nov, 2005 1 commit
  27. 24 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      Add git-shell. · 35eb2d36
      Linus Torvalds authored
      This adds a very git specific restricted shell, that can be
      added to /etc/shells and set to the pw_shell in the /etc/passwd
      file, to give users ability to push into repositories over ssh
      without giving them full interactive shell acount.
      
      [jc: I updated Linus' patch to match what the current sq_quote()
       does.]
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      35eb2d36