1. 28 8月, 2009 1 次提交
  2. 26 8月, 2009 1 次提交
  3. 24 8月, 2009 1 次提交
    • G
      gitweb: pull ref markes pull out of subject <a> element · 01b89f0c
      Giuseppe Bilotta 提交于
      Since 4afbaeff (gitweb: ref markers link to named shortlogs, 2008-09-02),
      ref markers that accompany the subject in views such as shortlog and
      history point to something different from the subject itself. Therefore,
      they should not be included in the same <a> element.
      
      Benefits of the change are:
      
       * better compliance to the XHTML standards, that forbid links within
         links even though the restriction cannot be imposed via DTD; this also
         benefits visualization in some older browsers;
      
       * when hovering the subject, only the subject itself is underlined; when
         hovering the ref markers, only the text in the hovered ref marker is
         underlined; previously, hovering any written part of the subject column
         led to complete underlying of everything at the same time, with
         unpleasing effects.
      Signed-off-by: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Acked-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      01b89f0c
  4. 07 8月, 2009 2 次提交
    • M
      gitweb: add support for XZ compressed snapshots · cbdefb5a
      Mark A Rada 提交于
      The XZ compression format uses the LZMA2 compression algorithm, which
      often yields higher compression ratios than both GZip and BZip2 at the
      cost of using more CPU time and RAM. XZ is the slowest for compression,
      but still much faster than BZip2 for decompression, almost comparable
      to GZip (see benchmarks below).
      
      Some simple benchmarks show the pros and cons of using XZ compression;
      starting with an already tarball'd archive of the repos listed below.
      Memory usage seemed to be consistent for any given algorithm at their
      respective default compression levels.
      
      CPU: AMD Sempron 3400+ (1 core @ 1.8GHz with 256K L2 cache)
      Virtual Memory Usage
             GZip: 4152K        BZip2: 13352K        XZ: 102M
      
      Linux 2.6 series (f5886c7f96f2542382d3a983c5f13e03d7fc5259)  349M
      gzip    23.70s user   0.47s system  99% cpu   24.227 total    76M
      gunzip  3.74s user    0.74s system  94% cpu   4.741 total
      bzip2   130.96s user  0.53s system  99% cpu   2:11.97 total   59M
      bunzip2 31.05s user   1.02s system  99% cpu   32.355 total
      xz      448.78s user  0.91s system  99% cpu   7:31.28 total   51M
      unxz    7.67s user    0.80s system  98% cpu   8.607 total
      
      Git (0a53e9dd)                11M
      gzip    0.77s user    0.03s system  99% cpu   0.792 total    2.5M
      gunzip  0.12s user    0.02s system  98% cpu   0.142 total
      bzip2   3.42s user    0.02s system  99% cpu   3.454 total    2.1M
      bunzip2 0.95s user    0.03s system  99% cpu   0.984 total
      xz      12.88s user   0.14s system  98% cpu   13.239 total   1.9M
      unxz    0.27s user    0.03s system  99% cpu   0.298 total
      
      XZ (669413bb2db954bbfde3c4542fddbbab53891eb4)                1.8M
      gzip    0.12s user    0.00s system  95% cpu   0.132 total    442K
      gunzip  0.02s user    0.00s system  97% cpu   0.027 total
      bzip2   1.28s user    0.01s system  99% cpu   1.298 total    363K
      bunzip2 0.15s user    0.01s system  100% cpu  0.157 total
      xz      1.62s user    0.03s system  99% cpu   1.652 total    347K
      unxz    0.05s user    0.00s system  99% cpu   0.058 total
      
      From a time and memory perspective, nothing compares to GZip, but if
      given an average upload speed of 20KB/s, it would take ~400 seconds
      longer to transfer the BZip2'd kernel snapshot than the XZ snapshot;
      the transfer time difference is even greater between GZip and XZ. The
      real time savings are relatively the same for all test cases, but less
      dramatic for smaller repositories.
      
      XZ decompresses ~1.8-2 times slower than GZip, and ~2.7-3.75 times
      faster than BZip2; XZ gets relatively faster as snapshots get larger.
      However, XZ takes relatively longer to compress as snapshots get larger.
      
      The downside for XZ'd snapshots is the large CPU and memory load put on
      the server to generate the compressed snapshot, though XZ will
      eventually
      have threading support, and the real clock time for making XZ'd
      snapshots
      would decrease if the server had a beefy multi-core CPU.
      
      XZ compression is disabled by default to allow upgrades to take place
      without any surprises, as the CPU and memory requirements will be an
      issue for high load or lightweight servers. Also, the XZ format is still
      new (format declared stable ~6 months ago), and there have been no
      "stable" releases of the utils yet.
      Signed-off-by: NMark Rada <marada@uwaterloo.ca>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cbdefb5a
    • M
      gitweb: support to globally disable a snapshot format · 1bfd3631
      Mark A Rada 提交于
      Allow Gitweb administrators to set a 'disabled' key in the
      %known_snapshot_formats hash to disable a specific snapshot format.
      
      All formats are enabled by default to maintain backwards compatibility.
      Signed-off-by: NMark Rada <marada@uwaterloo.ca>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1bfd3631
  5. 06 8月, 2009 1 次提交
  6. 04 8月, 2009 1 次提交
  7. 25 7月, 2009 5 次提交
    • J
      gitweb: Use light/dark for class names also in 'blame' view · aef37684
      Jakub Narebski 提交于
      Instead of using "light2" and "dark2" for class names in 'blame' view
      (in place of "light" and "dark" classes in other places) to avoid
      changing style on hover in 'blame' view while doing it for other views
      (like 'shortlog'), use more advanced CSS, relying on the fact that
      more specific selector wins.
      
      While at it add a few comments to gitweb CSS file, and consolidate
      some repeated info.
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      aef37684
    • J
      gitweb: Add author initials in 'blame' view, a la "git gui blame" · a36817b6
      Jakub Narebski 提交于
      For example for "Junio C Hamano" initials would be "JH".  Of course
      initials are added (below shortened SHA-1 of blamed commit) only if
      group of lines that blame the same commit has 2 or more lines in it.
      
      Initials are extracted using i18n /\b([[:upper:]])\B/g regexp.
      
      Additionally initials help to distinguish boundary commits, as they
      use bold weight font too (in addition to shortened SHA-1 of commit).
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a36817b6
    • J
      gitweb: Mark commits with no "previous" in 'blame' view · 3665e7e7
      Jakub Narebski 提交于
      Use "no-previous" class to mark blamed commits which do not have
      "previous" header.  Those are commits in which blamed file was created
      (added); this includes boundary commits.  This means that 'linenr'
      link leads to blamed commit, not (one of) parent of blamed commit.
      Therefore currently line number for such commit uses bold weight font
      to denote this situation; the effect is subtle.
      
      Use "multiple-previous" class in the opposite situation, where blamed
      commit has multiple "previous" headers (is an evil merge).  Currently
      this class is not used for styling.  In this situation 'linenr' link
      leads to first of "previous" commits (first parent).
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3665e7e7
    • J
      gitweb: Use "previous" header of git-blame -p in 'blame' view · 11930423
      Jakub Narebski 提交于
      Luben Tuikov changed 'lineno' link (line number link) from pointing to
      'blame' view at given line at blamed commit, to the one at parent of
      blamed commit in
        244a70e6 (Blame "linenr" link jumps to previous state at
                 "orig_lineno", 2007-01-04).
      This made it possible to do data mining using 'blame' view, by going
      through history of a line using mentioned line number link.
      
      Original implementation called "git rev-parse <commit>^" to find SHA-1
      of a parent of a given commit once per each blamed line.  In
        39c19ce2 (gitweb: cache $parent_commit info in git_blame(),
                 2008-12-11)
      this was improved so rev-parse was called once per each unique commit
      in git-blame output.  Alternate solution would be to relax validation
      for 'hb' parameter by allowing extended SHA-1 syntax of the form
      <rev>^ (perhaps redirecting to gitweb URL with <rev>^ resolved, in
      practice moving call to rev-parse to 'the other side of link').
      
      This solution had a bug that it didn't work for boundary commits.
      Boundary commits don't have parents, so "git rev-parse <commit>^"
      returned literal "<commit>^" (which didn't exists).  Gitweb didn't
      detect this situation and passed this result literally as 'hb'
      parameter in 'linenr' link.  Following such link currently gives
        400 - Invalid hash base parameter
      error; 'hb' parameter is restricted via validate_refname to correct
      refnames and doesn't allow for extended SHA-1 syntax.  This bug could
      have been fixed alternatively by checking if commit is boundary commit,
      or check if rev-parse result is unchanged (still ends in '^' prefix).
      
      The solution employing rev-parse to find parent of commit had inherent
      problem if blamed commit renamed file; then name of file would be
      different in its parent.  Solving this outside git-blame would be
      difficult and costly (at least cost of additional fork for extra git
      command).
      
      Currently gitweb uses information in "previous" header, which was
      introduced by Junio C Hamano in
        96e11709 (blame: show "previous" information in
                 --porcelain/--incremental format, 2008-06-04)
      This (currently undocumented) header has the following format:
        "previous <sha1 of parent commit> <filename at parent>"
      Using "previous" header solves both problem of performance and the
      problem that blamed commit could have renaming blamed file.
      
      Because "previous" header can be repeated for the same commit when
      blamed commit is merge (has more than one parent), and we are
      interested usually in _first_ parent, currently we store only first
      value if blame header repeats.  Using first parent (first "previous"
      line) was what gitweb did before; without this change gitweb would use
      last parent instead.
      
      If there is no previous commit 'linenr' link points to blamed commit
      and blamed filename, making it work correctly for boundary commits.
      Acked-by: NLuben Tuikov <ltuikov@yahoo.com>
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      11930423
    • J
      gitweb: Mark boundary commits in 'blame' view · 6de9433f
      Jakub Narebski 提交于
      Use "boundary" class to mark boundary commits, which currently results
      in using bold weight font for SHA-1 of a commit (to be more exact for
      all text in the first cell in row, that contains SHA-1 of a commit).
      
      Detecting boundary commits is done by watching for "boundary" header
      in "git blame -p" output.  Because this header doesn't carry
      additional data the regular expression for blame header fields
      had to be slightly adjusted.
      
      With current gitweb API only root (parentless) commits can be boundary
      commits.
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6de9433f
  8. 14 7月, 2009 1 次提交
  9. 01 7月, 2009 7 次提交
  10. 23 5月, 2009 1 次提交
    • J
      gitweb: Sanitize title attribute in format_subject_html · 14afe774
      Jakub Narebski 提交于
      Replace control characters with question mark '?' (like in
      chop_and_esc_str).
      
      A little background: some web browsers turn on strict (and
      unforgiving) XML validating mode for XHTML documents served using
      application/xhtml+xml content type.  This means among others that
      control characters are forbidden to appear in gitweb output.
      
      CGI.pm does by default slight escaping (using simple_escape subroutine
      from CGI::Util) of all _attribute_ values (depending on the value of
      autoEscape, by default on).  This escaping, at least in CGI.pm version
      3.10 (most current version at CPAN is 3.43), is minimal: only '"',
      '&', '<' and '>' are escaped using named HTML entity references
      (&quot;, &amp;, &lt; and &gt; respectively).  But simple_escape does
      not do escaping of control characters such as ^X which are invalid in
      XHTML (in strict mode).
      
      If by some accident commit message do contain some control character
      in first 50 characters (more or less) of first line of commit message,
      and this line is longer than 50 characters (so gitweb shortens it for
      display), then gitweb would put this control character in title
      attribute (and CGI.pm would not remove them).  The tag _contents_ is
      safe because it is escaped using esc_html() explicitly, and it
      replaces control characters by their printable representation.
      
      While at it: chop_and_escape_str doesn't need capturing group.
      Noticed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      14afe774
  11. 14 5月, 2009 4 次提交
  12. 11 5月, 2009 4 次提交
    • J
      gitweb: Use block form of map/grep in a few cases more · 68cedb1f
      Jakub Narebski 提交于
      Use block form of 'grep' i.e. 'grep {BLOCK} LIST' rather than
      'grep(EXPR, LIST)' in filter_snapshot_fmts subroutine.  This makes
      code more readable, as expression is rather long, and statement above
      there is 'map' with very similar expression also in the block form.
      
      Remove unnecessary and misleading parentheses around block form 'map'
      arguments in quote_command subroutine.
      
      The inner "map" in format_snapshot_links was left alone, as it is not
      clear whether adding parentheses or changing it into block form would
      improve readibility and clarity of this code.
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      68cedb1f
    • J
      gitweb: Always use three argument form of open · 34122b57
      Jakub Narebski 提交于
      From 94638fb6edf3ea693228c680a6a30271ccd77522 Mon Sep 17 00:00:00 2001
      From: Jakub Narebski <jnareb@gmail.com>
      Date: Mon, 11 May 2009 03:25:55 +0200
      Subject: [PATCH] gitweb: Localize magic variable $/
      
      Instead of undefining and then restoring magic variable $/ (input
      record separator) for 'slurp mode', localize it.
      
      While at it, state explicitely that "local $/;" makes it undefined, by
      using explicit  "local $/ = undef;".
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      34122b57
    • J
      gitweb: Always use three argument form of open · dff2b6d4
      Jakub Narebski 提交于
      In most cases (except insert_file() subroutine) we used old two argument
      form of 'open' to open files for reading.  This can cause subtle bugs when
      $projectroot or $projects_list file starts with mode characters ('>', '<',
      '+<', '|', etc.) or with leading whitespace; and also when $projects_list
      file or $mimetypes_file or ctags files end with trailing whitespace or '|'.
      
      Additionally it is also more clear to explicitly state that we open those
      files for reading.
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dff2b6d4
    • J
      gitweb: Do not use bareword filehandles · ad87e4f6
      Jakub Narebski 提交于
      gitweb: Do not use bareword filehandles
      
      The script was using bareword filehandles.  This is considered a bad
      practice so they have been changed to indirect filehandles.
      
      Changes touch git_get_project_ctags and mimetype_guess_file;
      while at it rename local variable from $mime to $mimetype (in
      mimetype_guess_file) to better reflect its value (its contents).
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ad87e4f6
  13. 09 5月, 2009 1 次提交
    • J
      gitweb: Remove function prototypes (cleanup) · 74fd8728
      Jakub Narebski 提交于
      Use of function prototypes is considered bad practice in Perl.  The
      ones used here didn't accomplish anything anyhow, so they've been
      removed.
      
      >From perlsub(1):
      
        [...] the intent of this feature [prototypes] is primarily to let
        you define subroutines that work like built-in functions [...]
        you can generate new syntax with it [...]
      
      We don't want to have subroutines behaving exactly like built-in
      functions, we don't want to define new syntax / syntactic sugar, so
      prototypes in gitweb are not needed... and they can have unintended
      consequences.
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      74fd8728
  14. 20 4月, 2009 1 次提交
  15. 20 2月, 2009 1 次提交
    • M
      gitweb: Hyperlink multiple git hashes on the same commit message line · 7d233dea
      Marcel M. Cary 提交于
      The current implementation only hyperlinks the first hash on
      a given line of the commit message.  It seems sensible to
      highlight all of them if there are multiple, and it seems
      plausible that there would be multiple even with a tidy line
      length limit, because they can be abbreviated as short as 8
      characters.
      
      Benchmark:
      
      I wanted to make sure that using the 'e' switch to the Perl regex
      wasn't going to kill performance, since this is called once per commit
      message line displayed.
      
      In all three A/B scenarios I tried, the A and B yielded the same
      results within 2%, where A is the version of code before this patch
      and B is the version after.
      
      1: View a commit message containing the last 1000 commit hashes
      2: View a commit message containing 1000 lines of 40 dots to avoid
         hyperlinking at the same message length
      3: View a short merge commit message with a few lines of text and
         no hashes
      
      All were run in CGI mode on my sub-production hardware on a recent
      clone of git.git.  Numbers are the average of 10 reqests per second
      with the first request discarded, since I expect this change to affect
      primarily CPU usage.  Measured with ApacheBench.
      
      Note that the web page rendered was the same; while the new code
      supports multiple hashes per line, there was at most one per line.
      
      The primary purpose of scenarios 2 and 3 were to verify that the
      addition of 1000 commit messages had an impact on how much of the time
      was spent rendering commit messages.  They were all within 2% of 0.80
      requests per second (much faster).
      
      So I think the patch has no noticeable effect on performance.
      Signed-off-by: NMarcel M. Cary <marcel@oak.homeunix.org>
      Acked-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7d233dea
  16. 19 2月, 2009 1 次提交
    • M
      gitweb: Fix warnings with override permitted but no repo override · df5d10a3
      Marcel M. Cary 提交于
      When a feature like "blame" is permitted to be overridden in the
      repository configuration but it is not actually set in the repository,
      a warning is emitted due to the undefined value of the repository
      configuration, even though it's a perfectly normal condition.
      Emitting warning is grounds for test failure in the gitweb test
      script.
      
      This error was caused by rewrite of git_get_project_config from using
      "git config [<type>] <name>" for each individual configuration
      variable checked to parsing "git config --list --null" output in
      commit b201927a (gitweb: Read repo config using 'git config -z -l').
      Earlier version of git_get_project_config was returning empty string
      if variable do not exist in config; newer version is meant to return
      undef in this case, therefore change in feature_bool was needed.
      
      Additionally config_to_* subroutines were meant to be invoked only if
      configuration variable exists; therefore we added early return to
      git_get_project_config: it now returns no value if variable does not
      exists in config.  Otherwise config_to_* subroutines (config_to_bool
      in paryicular) wouldn't be able to distinguish between the case where
      variable does not exist and the case where variable doesn't have value
      (the "[section] noval" case, which evaluates to true for boolean).
      
      While at it fix bug in config_to_bool, where checking if $val is
      defined (if config variable has value) was done _after_ stripping
      leading and trailing whitespace, which lead to 'Use of uninitialized
      value' warning.
      
      Add test case for features overridable but not overriden in repo
      config, and case for no value boolean configuration variable.
      Signed-off-by: NMarcel M. Cary <marcel@oak.homeunix.org>
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      df5d10a3
  17. 17 2月, 2009 1 次提交
    • G
      gitweb: fix wrong base URL when non-root DirectoryIndex · 81d3fe9f
      Giuseppe Bilotta 提交于
      CGI::url() has some issues when rebuilding the script URL if the script
      is a DirectoryIndex.
      
      One of these issue is the inability to strip PATH_INFO, which is why
      we had to do it ourselves.
      
      Another issue is that the resulting URL cannot be used for the <base>
      tag: it works if we're the DirectoryIndex at the root level, but not
      otherwise.
      
      We fix this by building the proper base URL ourselves, and improve the
      comment about the need to strip PATH_INFO manually while we're at it.
      
      Additionally t/t9500-gitweb-standalone-no-errors.sh had to be modified
      to set SCRIPT_NAME variable (CGI standard states that it MUST be set,
      and now gitweb uses it if PATH_INFO is not empty, as is the case for
      some of tests in t9500).
      Signed-off-by: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      81d3fe9f
  18. 09 2月, 2009 1 次提交
  19. 08 2月, 2009 1 次提交
  20. 31 1月, 2009 2 次提交
  21. 29 1月, 2009 2 次提交