1. 10 Mar, 2015 2 commits
  2. 27 May, 2014 1 commit
  3. 03 Feb, 2014 1 commit
  4. 29 Oct, 2013 1 commit
    • Jeff King's avatar
      use @@perl@@ in built scripts · fcb06a8d
      Jeff King authored
      Several of the built shell commands invoke a bare "perl" to
      perform some one-liners. This will use the first perl in the
      PATH rather than the one specified by the user's SHELL_PATH.
      We are not asking these perl invocations to do anything
      exotic, so typically any old system perl will do; however,
      in some cases the system perl may have unexpected behavior
      (e.g., by handling line endings differently). We should err
      on the side of using the perl the user pointed us to.
      The downside of this is that on systems with a sane perl
      setup, we no longer find the perl at runtime, but instead
      point to a static perl (like /usr/bin/perl). That means we
      will not handle somebody moving perl without rebuilding git,
      whereas before we tracked it just fine. This is probably not
      a big deal, though, as the built perl scripts already
      suffered from this.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 27 Jun, 2011 4 commits
  6. 28 Feb, 2011 1 commit
  7. 17 Nov, 2010 1 commit
  8. 05 Aug, 2010 3 commits
  9. 23 Jul, 2010 3 commits
  10. 02 Jun, 2010 3 commits
    • Jakub Narębski's avatar
      git-instaweb: Add support for running gitweb via 'plackup' · 78646987
      Jakub Narębski authored
      PSGI is an interface between Perl web applications and web servers, and
      Plack is a Perl module and toolkit that contains PSGI middleware, helpers
      and adapters to web servers; see http://plackperl.org
      PSGI and Plack are inspired by Python's WSGI and Ruby's Rack (and
      probably JavaScript's Jack/JSGI).
      Plack core distribution includes HTTP::Server::PSGI, a reference PSGI
      standalone web server implementation.  'plackup' is a command line
      launcher to run PSGI applications from command line, connecting web
      app to a web server via Plack::Runner module.  By default it uses
      HTTP::Server::PSGI as a web server.
      git-instaweb generates gitweb.psgi wrapper (in $GIT_DIR/gitweb).  This
      wrapper uses Plack::App::WrapCGI to compile gitweb.cgi (which is a CGI
      script) into a PSGI application using CGI::Compile and CGI::Emulate::PSGI.
      git-instaweb then runs this wrapper, using by default HTTP::Server::PSGI
      standalone Perl server, via Plack::Runner.
      The configuration for 'plackup' is currently embedded in generated
      gitweb.psgi wrapper, instead of using httpd.conf ($conf).
      To run git-instaweb with '--httpd=plackup', you need to have instaled
      Plack core, CGI::Emulate::PSGI, CGI::Compile.  Those modules have to be
      available for Perl scripts (which can be done for example by setting
      PERL5LIB environment variable).  This is currently not documented.
      Signed-off-by: Jakub Narębski's avatarJakub Narebski <jnareb@gmail.com>
      Acked-by: default avatarPetr Baudis <pasky@suse.cz>
      Acked-by: default avatarEric Wong <normalperson@yhbt.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jakub Narębski's avatar
      git-instaweb: Wait for server to start before running web browser · d94775e1
      Jakub Narębski authored
      Add generic httpd_is_ready subroutine, which busy-waits for web server to
      be started, by checking if $port is opened on localhost.  This is used to
      avoid situation where web browser is started before web server is ready to
      accept connection, and fails.
      It uses IO::Socket::INET module, which is core Perl module since v5.6.0.
      Alternate solution, possible for those web servers that can run arbitrary
      code hooks after they bind the listen socket (after they start accepting
      connections), would be to use some kind of blocking mechanism: FIFO or
      lockfile, see
      This can be always added later, as a web server specific branch in
      httpd_is_ready function.
      Signed-off-by: Jakub Narębski's avatarJakub Narebski <jnareb@gmail.com>
      Acked-by: default avatarPetr Baudis <pasky@suse.cz>
      Acked-by: default avatarEric Wong <normalperson@yhbt.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jakub Narębski's avatar
      git-instaweb: Remove pidfile after stopping web server · d1127622
      Jakub Narębski authored
      This way running e.g. "git instaweb" after "git instaweb --stop" would
      not try to kill already stopped web server.
      This is probably important only for those web servers that are
      "daemonized" by git-instaweb itself, i.e. for those where it is
      git-instaweb that creates pidfile.  Currently it is includes only
      'mongoose' web server, but it would also include 'plackup' web server
      (added in later commit).
      Signed-off-by: Jakub Narębski's avatarJakub Narebski <jnareb@gmail.com>
      Acked-by: default avatarPetr Baudis <pasky@suse.cz>
      Acked-by: default avatarEric Wong <normalperson@yhbt.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 01 Jun, 2010 2 commits
  12. 17 Apr, 2010 1 commit
  13. 03 Apr, 2010 1 commit
    • Mark Rada's avatar
      instaweb: add minification awareness · 09b89d1a
      Mark Rada authored
      This patch will cause git-instaweb to use the minified version of gitweb
      support files (e.g. CSS and JavaScript) if they were generated.
      Without minification awareness, generating the minified version of
      gitweb's support files will generate a broken instaweb script since the
      copy of gitweb.cgi will look for gitweb.min.* which will not exist.
      Signed-off-by: default avatarMark Rada <marada@uwaterloo.ca>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  14. 26 Jan, 2010 1 commit
  15. 24 Nov, 2009 2 commits
    • Stephen Boyd's avatar
      instaweb: restart server if already running · 0b624b4c
      Stephen Boyd authored
      Running 'git instaweb' when an instaweb server is already running will
      fail (at least when the port is the same) and overwrite the pid file
      used to track the currently running server. This turns out to be
      especially annoying when the user tries to stop the previously running
      server with 'git instaweb --stop' and is instead greeted with an error
      message because the pid file has been destroyed.
      Instead of allowing a user to start two instaweb servers, stop the
      currently running server first and then start the new one. This should
      be fine because it was never really possible to start two instaweb
      servers in the first place due to the pid file issue outlined above.
      Signed-off-by: default avatarStephen Boyd <bebarino@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Junio C Hamano's avatar
      Protect scripted Porcelains from GREP_OPTIONS insanity · e1622bfc
      Junio C Hamano authored
      If the user has exported the GREP_OPTIONS environment variable, the output
      from "grep" and "egrep" in scripted Porcelains may be different from what
      they expect.  For example, we may want to count number of matching lines,
      by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use.
      The approach taken by this change to address this issue is to protect only
      our own use of grep/egrep.  Because we do not unset it at the beginning of
      our scripts, hook scripts run from the scripted Porcelains are exposed to
      the same insanity this environment variable causes when grep/egrep is used
      to implement logic (e.g. "grep | wc -l"), and it is entirely up to the
      hook scripts to protect themselves.
      On the other hand, applypatch-msg hook may want to show offending words in
      the proposed commit log message using grep to the end user, and the user
      might want to set GREP_OPTIONS=--color to paint the match more visibly.
      The approach to protect only our own use without unsetting the environment
      variable globally will allow this use case.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  16. 29 Sep, 2009 1 commit
  17. 01 Sep, 2009 1 commit
    • Jakub Narębski's avatar
      gitweb: Incremental blame (using JavaScript) · 4af819d4
      Jakub Narębski authored
      Add 'blame_incremental' view, which uses "git blame --incremental"
      and JavaScript (Ajax), where 'blame' use "git blame --porcelain".
       * gitweb generates initial info by putting file contents (from
         "git cat-file") together with line numbers in blame table
       * then gitweb makes web browser JavaScript engine call startBlame()
         function from gitweb.js
       * startBlame() opens XMLHttpRequest connection to 'blame_data' view,
         which in turn calls "git blame --incremental" for a file, and
         streams output of git-blame to JavaScript (gitweb.js)
       * XMLHttpRequest event handler updates line info in blame view as soon
         as it gets data from 'blame_data' (from server), and it also updates
         progress info
       * when 'blame_data' ends, and gitweb.js finishes updating line info,
         it fixes colors to match (as far as possible) ordinary 'blame' view,
         and updates information about how long it took to generate page.
      Gitweb deals with streamed 'blame_data' server errors by displaying
      them in the progress info area (just in case).
      The 'blame_incremental' view tries to be equivalent to 'blame' action;
      there are however a few differences in output between 'blame' and
      'blame_incremental' view:
       * 'blame_incremental' always used query form for this part of link(s)
         which is generated by JavaScript code.  The difference is visible
         if we use path_info link (pass some or all arguments in path_info).
         Changing this would require implementing something akin to href()
         subroutine from gitweb.perl in JavaScript (in gitweb.js).
       * 'blame_incremental' always uses "rowspan" attribute, even if
         rowspan="1".  This simplifies code, and is not visible to user.
       * The progress bar and progress info are still there even after
         JavaScript part of 'blame_incremental' finishes work.
      Note that currently no link generated by gitweb leads to this new view.
      This code is based on patch by Petr Baudis <pasky@suse.cz> patch, which
      in turn was tweaked up version of Fredrik Kuivinen <frekui@gmail.com>'s
      proof of concept patch.
      This patch adds GITWEB_JS compile configuration option, and modifies
      git-instaweb.sh to take gitweb.js into account.  The code for
      git-instaweb.sh was taken from Pasky's patch.
      Signed-off-by: Fredrik K's avatarFredrik Kuivinen <frekui@gmail.com>
      Signed-off-by: default avatarPetr Baudis <pasky@suse.cz>
      Signed-off-by: Jakub Narębski's avatarJakub Narebski <jnareb@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  18. 23 Aug, 2009 1 commit
  19. 10 Aug, 2009 1 commit
  20. 26 Jul, 2009 1 commit
  21. 11 Mar, 2009 1 commit
  22. 13 Jul, 2008 1 commit
    • Stephan Beyer's avatar
      Make usage strings dash-less · 1b1dd23f
      Stephan Beyer authored
      When you misuse a git command, you are shown the usage string.
      But this is currently shown in the dashed form.  So if you just
      copy what you see, it will not work, when the dashed form
      is no longer supported.
      This patch makes git commands show the dash-less version.
      For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
      generates a dash-less usage string now.
      Signed-off-by: default avatarStephan Beyer <s-beyer@gmx.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  23. 14 Jun, 2008 1 commit
  24. 05 Feb, 2008 1 commit
  25. 29 Jan, 2008 1 commit
  26. 19 Dec, 2007 1 commit
  27. 09 Dec, 2007 1 commit
  28. 09 Nov, 2007 1 commit