1. 28 Nov, 2012 1 commit
    • Jeff King's avatar
      fsck: warn about '.' and '..' in trees · 5d34a435
      Jeff King authored
      A tree with meta-paths like '.' or '..' does not work well
      with git; the index will refuse to load it or check it out
      to the filesystem (and even if we did not have that safety,
      it would look like we were overwriting an untracked
      directory). For the same reason, it is difficult to create
      such a tree with regular git.
      
      Let's warn about these dubious entries during fsck, just in
      case somebody has created a bogus tree (and this also lets
      us prevent them from propagating when transfer.fsckObjects
      is set).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5d34a435
  2. 17 Oct, 2012 12 commits
  3. 14 Oct, 2012 1 commit
  4. 12 Oct, 2012 2 commits
    • Jeff King's avatar
      http: fix segfault in handle_curl_result · 188923f0
      Jeff King authored
      When we create an http active_request_slot, we can set its
      "results" pointer back to local storage. The http code will
      fill in the details of how the request went, and we can
      access those details even after the slot has been cleaned
      up.
      
      Commit 88097030 (http: factor out http error code handling)
      switched us from accessing our local results struct directly
      to accessing it via the "results" pointer of the slot. That
      means we're accessing the slot after it has been marked as
      finished, defeating the whole purpose of keeping the results
      storage separate.
      
      Most of the time this doesn't matter, as finishing the slot
      does not actually clean up the pointer. However, when using
      curl's multi interface with the dumb-http revision walker,
      we might actually start a new request before handing control
      back to the original caller. In that case, we may reuse the
      slot, zeroing its results pointer, and leading the original
      caller to segfault while looking for its results inside the
      slot.
      
      Instead, we need to pass a pointer to our local results
      storage to the handle_curl_result function, rather than
      relying on the pointer in the slot struct. This matches what
      the original code did before the refactoring (which did not
      use a separate function, and therefore just accessed the
      results struct directly).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      188923f0
    • Dylan Simon's avatar
      gitweb.cgi: fix "comitter_tz" typo in feed · debf29dc
      Dylan Simon authored
      gitweb's feeds sometimes contained committer timestamps in the wrong timezone
      due to a misspelling.
      Signed-off-by: Dylan Simon's avatarDylan Simon <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      debf29dc
  5. 10 Oct, 2012 1 commit
  6. 09 Oct, 2012 1 commit
  7. 08 Oct, 2012 8 commits
  8. 07 Oct, 2012 1 commit
  9. 05 Oct, 2012 1 commit
  10. 04 Oct, 2012 1 commit
  11. 02 Oct, 2012 6 commits
    • Junio C Hamano's avatar
      t1450: the order the objects are checked is undefined · 9dad83be
      Junio C Hamano authored
      When a tag T points at an object X that is of a type that is
      different from what the tag records as, fsck should report it as an
      error.
      
      However, depending on the order X and T are checked individually,
      the actual error message can be different.  If X is checked first,
      fsck remembers X's type and then when it checks T, it notices that T
      records X as a wrong type (i.e. the complaint is about a broken tag
      T).  If T is checked first, on the other hand, fsck remembers that we
      need to verify X is of the type tag records, and when it later
      checks X, it notices that X is of a wrong type (i.e. the complaint
      is about a broken object X).
      
      The important thing is that fsck notices such an error and diagnoses
      the issue on object X, but the test was expecting that we happen to
      check objects in the order to make us detect issues with tag T, not
      with object X.  Remove this unwarranted assumption.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9dad83be
    • Junio C Hamano's avatar
      Start preparing for 1.7.12.3 · 9376c860
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9376c860
    • Junio C Hamano's avatar
      Merge branch 'rr/maint-submodule-unknown-cmd' into maint · e2c7a5b6
      Junio C Hamano authored
      "git submodule frotz" was not diagnosed as "frotz" being an unknown
      subcommand to "git submodule"; the user instead got a complaint that
      "git submodule status" was run with an unknown path "frotz".
      
      * rr/maint-submodule-unknown-cmd:
        submodule: if $command was not matched, don't parse other args
      e2c7a5b6
    • Junio C Hamano's avatar
      Merge branch 'sp/maint-http-enable-gzip' into maint · 0a65df58
      Junio C Hamano authored
      "git fetch" over http advertised that it supports "deflate", which
      is much less common, and did not advertise more common "gzip" on its
      Accept-Encoding header.
      
      * sp/maint-http-enable-gzip:
        Enable info/refs gzip decompression in HTTP client
      0a65df58
    • Junio C Hamano's avatar
      Merge branch 'sp/maint-http-info-refs-no-retry' into maint · 8a477ddf
      Junio C Hamano authored
      "git fetch" over http had an old workaround for an unlikely server
      misconfiguration; it turns out that this hurts debuggability of the
      configuration in general, and has been reverted.
      
      * sp/maint-http-info-refs-no-retry:
        Revert "retry request without query when info/refs?query fails"
      8a477ddf
    • Peter Krefting's avatar
      l10n: Fix to Swedish translation · a9073097
      Peter Krefting authored
      Fix bad translation of "Receiving objects".
      Signed-off-by: default avatarPeter Krefting <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a9073097
  12. 01 Oct, 2012 1 commit
    • Linus Torvalds's avatar
      mailinfo: don't require "text" mime type for attachments · 9d55b2e1
      Linus Torvalds authored
      Currently "git am" does insane things if the mbox it is given contains
      attachments with a MIME type that aren't "text/*".
      
      In particular, it will still decode them, and pass them "one line at a
      time" to the mail body filter, but because it has determined that they
      aren't text (without actually looking at the contents, just at the mime
      type) the "line" will be the encoding line (eg 'base64') rather than a
      line of *content*.
      
      Which then will cause the text filtering to fail, because we won't
      correctly notice when the attachment text switches from the commit message
      to the actual patch. Resulting in a patch failure, even if patch may be a
      perfectly well-formed attachment, it's just that the message type may be
      (for example) "application/octet-stream" instead of "text/plain".
      
      Just remove all the bogus games with the message_type. The only difference
      that code creates is how the data is passed to the filter function
      (chunked per-pred-code line or per post-decode line), and that difference
      is *wrong*, since chunking things per pre-decode line can never be a
      sensible operation, and cannot possibly matter for binary data anyway.
      
      This code goes all the way back to March of 2007, in commit 87ab7992
      ("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to
      pass random mbox contents to git. However, the pre-decode vs post-decode
      logic really shouldn't matter even for that case, and more importantly, "I
      fed git am crap" is not a valid reason to break *real* patch attachments.
      
      If somebody really cares, and determines that some attachment is binary
      data (by looking at the data, not the MIME-type), the whole attachment
      should be dismissed, rather than fed in random-sized chunks to
      "handle_filter()".
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Cc: Don Zickus <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9d55b2e1
  13. 30 Sep, 2012 4 commits