1. 02 Jun, 2013 1 commit
    • Michael Haggerty's avatar
      object_array_entry: fix memory handling of the name field · 31faeb20
      Michael Haggerty authored
      Previously, the memory management of the object_array_entry::name
      field was inconsistent and undocumented.  object_array_entries are
      ultimately created by a single function, add_object_array_with_mode(),
      which has an argument "const char *name".  This function used to
      simply set the name field to reference the string pointed to by the
      name parameter, and nobody on the object_array side ever freed the
      memory.  Thus, it assumed that the memory for the name field would be
      managed by the caller, and that the lifetime of that string would be
      at least as long as the lifetime of the object_array_entry.  But
      callers were inconsistent:
      * Some passed pointers to constant strings or argv entries, which was
      * Some passed pointers to newly-allocated memory, but didn't arrange
        for the memory ever to be freed.
      * Some passed the return value of sha1_to_hex(), which is a pointer to
        a statically-allocated buffer that can be overwritten at any time.
      * Some passed pointers to refnames that they received from a
        for_each_ref()-type iteration, but the lifetimes of such refnames is
        not guaranteed by the refs API.
      Bring consistency to this mess by changing object_array to make its
      own copy for the object_array_entry::name field and free this memory
      when an object_array_entry is deleted from the array.
      Many callers were passing the empty string as the name parameter, so
      as a performance optimization, treat the empty string specially.
      Instead of making a copy, store a pointer to a statically-allocated
      empty string to object_array_entry::name.  When deleting such an
      entry, skip the free().
      Change the callers that were already passing copies to
      add_object_array_with_mode() to either skip the copy, or (if the
      memory needed to be allocated anyway) freeing the memory itself.
      A part of this commit effectively reverts
          70d26c6e read_revisions_from_stdin: make copies for handle_revision_arg
      because the copying introduced by that commit (which is still
      necessary) is now done at a deeper level.
      Signed-off-by: default avatarMichael Haggerty <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 07 Apr, 2013 1 commit
    • Lukas Fleischer's avatar
      bundle: Accept prerequisites without commit messages · 5446e33f
      Lukas Fleischer authored
      While explicitly stating that the commit message in a prerequisite
      line is optional, we required all lines with 40 or more characters
      to contain a space after the object name, bailing out if a line
      consisted of an object name only. This was to allow bundling a
      history to a commit without an message, but the code forgot that it
      already called rtrim() to remove that whitespace.
      As a workaround, only check for SP when the line has more than 40
      Signed-off-by: default avatarLukas Fleischer <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 17 Mar, 2013 1 commit
    • Jeff King's avatar
      avoid segfaults on parse_object failure · 75a95490
      Jeff King authored
      Many call-sites of parse_object assume that they will get a
      non-NULL return value; this is not the case if we encounter
      an error while parsing the object.
      This patch adds a wrapper function around parse_object that
      handles dying automatically, and uses it anywhere we
      immediately try to access the return value as a non-NULL
      pointer (i.e., anywhere that we would currently segfault).
      This wrapper may also be useful in other places. The most
      obvious one is code like:
        o = parse_object(sha1);
        if (!o)
      However, these should not be mechanically converted to
      parse_object_or_die, as the die message is sometimes
      customized. Later patches can address these sites on a
      case-by-case basis.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  4. 08 Mar, 2013 1 commit
  5. 07 Mar, 2013 1 commit
  6. 04 Jun, 2012 1 commit
    • Junio C Hamano's avatar
      tweak "bundle verify" of a complete history · 8c3710fd
      Junio C Hamano authored
      A bundle that records a complete history without prerequiste is a
      useful way to sneakernet the sources of your configuration files
      under your home directory, etc.  E.g.
          $ GIT_DIR=/srv/git/homesrc.git git bundle create x.bndl HEAD master
      Running "git bundle verify" on such a "complete" bundle, however,
      gives somewhat a funny output.
          $ git bundle verify x.bndl
          The bundle contains 2 refs
          b2611f37ebc7ed6435a72d77fbc5f8b48a7d7146 HEAD
          b2611f37ebc7ed6435a72d77fbc5f8b48a7d7146 refs/heads/master
          The bundle requires these 0 refs
          x.bndl is okay
      Reword "requires these 0 refs" to say "The bundle records a complete
      history" instead.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  7. 26 Apr, 2012 1 commit
    • Jonathan Nieder's avatar
      bundle: remove stray single-quote from error message · 97afde15
      Jonathan Nieder authored
      After running rev-list --boundary to retrieve the list of boundary
      commits, "git bundle create" runs its own revision walk.  If in this
      stage git encounters an unfamiliar option, it writes a message with an
      unbalanced quotation mark:
      	error: unrecognized argument: --foo'
      Drop the stray quote to match the "unrecognized argument: %s" message
      used elsewhere and save translators some work.
      This is mostly a futureproofing measure: for now, the "rev-list
      --boundary" command catches most strange arguments on its own and the
      above message is not seen unless you try something esoteric like "git
      bundle create test.bundle --header HEAD".
      Reported-by: default avatarJunio C Hamano <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  8. 24 Apr, 2012 1 commit
  9. 01 Mar, 2012 1 commit
    • Thomas Rast's avatar
      bundle: keep around names passed to add_pending_object() · efe4be12
      Thomas Rast authored
      The 'name' field passed to add_pending_object() is used to later
      deduplicate in object_array_remove_duplicates().
      git-bundle had a bug in this area since 18449ab0 (git-bundle: avoid
      packing objects which are in the prerequisites, 2007-03-08): it passed
      the name of each boundary object in a static buffer.  In other words,
      all that object_array_remove_duplicates() saw was the name of the
      *last* added boundary object.
      The recent switch to a strbuf in bc2fed49 (bundle: use a strbuf to scan
      the log for boundary commits, 2012-02-22) made this slightly worse: we
      now free the buffer at the end, so it is not even guaranteed that it
      still points into addressable memory by the time object_array_remove_
      duplicates looks at it.  On the plus side however, it was now
      detectable by valgrind.
      The fix is easy: pass a copy of the string to add_pending_object.
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  10. 23 Feb, 2012 2 commits
    • Thomas Rast's avatar
      bundle: use a strbuf to scan the log for boundary commits · bc2fed49
      Thomas Rast authored
      The first part of the bundle header contains the boundary commits, and
      could be approximated by
        # v2 git bundle
        $(git rev-list --pretty=oneline --boundary <ARGS> | grep ^-)
      git-bundle actually spawns exactly this rev-list invocation, and does
      the grepping internally.
      There was a subtle bug in the latter step: it used fgets() with a
      1024-byte buffer.  If the user has sufficiently long subjects (e.g.,
      by not adhering to the git oneline-subject convention in the first
      place), the 'oneline' format can easily overflow the buffer.  fgets()
      then returns the rest of the line in the next call(s).  If one of
      these remaining parts started with '-', git-bundle would mistakenly
      insert it into the bundle thinking it was a boundary commit.
      Fix it by using strbuf_getwholeline() instead, which handles arbitrary
      line lengths correctly.
      Note that on the receiving side in parse_bundle_header() we were
      already using strbuf_getwholeline_fd(), so that part is safe.
      Reported-by: default avatarJannis Pohlmann <[email protected]>
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Thomas Rast's avatar
      bundle: put strbuf_readline_fd in strbuf.c with adjustments · 5e8617f5
      Thomas Rast authored
      The comment even said that it should eventually go there.  While at
      it, match the calling convention and name of the function to the
      strbuf_get*line family.  So it now is strbuf_getwholeline_fd.
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  11. 03 Jan, 2012 1 commit
  12. 13 Nov, 2011 1 commit
  13. 13 Oct, 2011 2 commits
    • Junio C Hamano's avatar
      bundle: add parse_bundle_header() helper function · 2727b71f
      Junio C Hamano authored
      Move most of the code from read_bundle_header() to parse_bundle_header()
      that takes a file descriptor that is already opened for reading, and make
      the former responsible only for opening the file and noticing errors.
      As a logical consequence of this, is_bundle() helper function can be
      implemented as a non-complaining variant of read_bundle_header() that
      does not return an open file descriptor, and can be used to tighten
      the check used to decide the use of bundle transport in transport_get()
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      bundle: allowing to read from an unseekable fd · e9ee84cf
      Junio C Hamano authored
      We wished that "git bundle" to eventually learn to read from a network
      socket which is not seekable. The current code opens with fopen(), reads
      the file halfway and run ftell(), and reopens the same file with open()
      and seeks, to skip the header.
      This patch by itself does not reach that goal yet, but I think it is a
      right step in that direction.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  14. 03 Oct, 2011 2 commits
  15. 19 Sep, 2011 1 commit
    • Junio C Hamano's avatar
      Teach progress eye-candy to fetch_refs_from_bundle() · be042aff
      Junio C Hamano authored
      With the usual "git" transport, a large-ish transfer with "git fetch" and
      "git pull" give progress eye-candy to avoid boring users.  However, not
      when they are reading from a bundle. I.e.
          $ git pull ../git-bundle.bndl master
      This teaches bundle.c:unbundle() to give "-v" option to index-pack and
      tell it to give progress bar when transport decides it is necessary.
      The operation in the other direction, "git bundle create", could also
      learn to honor --quiet but that is a separate issue.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  16. 07 Feb, 2011 1 commit
  17. 27 Aug, 2010 1 commit
  18. 24 Nov, 2009 1 commit
    • Nicolas Pitre's avatar
      pack-objects: split implications of --all-progress from progress activation · 4f366275
      Nicolas Pitre authored
      Currently the --all-progress flag is used to use force progress display
      during the writing object phase even if output goes to stdout which is
      primarily the case during a push operation.  This has the unfortunate
      side effect of forcing progress display even if stderr is not a
      Let's introduce the --all-progress-implied argument which has the same
      intent except for actually forcing the activation of any progress
      display.  With this, progress display will be automatically inhibited
      whenever stderr is not a terminal, or full progress display will be
      included otherwise.  This should let people use 'git push' within a cron
      job without filling their logs with useless percentage displays.
      Signed-off-by: Nicolas Pitre's avatarNicolas Pitre <[email protected]>
      Tested-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  19. 20 Nov, 2009 1 commit
    • Junio C Hamano's avatar
      Teach --stdin option to "log" family · 8b3dce56
      Junio C Hamano authored
      Move the logic to read revs from standard input that rev-list knows about
      from it to revision machinery, so that all the users of setup_revisions()
      can feed the list of revs from the standard input when "--stdin" is used
      on the command line.
      Allow some users of the revision machinery that want different semantics
      from the "--stdin" option to disable it by setting an option in the
      rev_info structure.
      This also cleans up the kludge made to bundle.c via cut and paste.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  20. 13 Sep, 2009 1 commit
  21. 21 May, 2009 1 commit
  22. 18 Jan, 2009 1 commit
  23. 05 Jan, 2009 1 commit
  24. 11 Nov, 2008 1 commit
  25. 19 Oct, 2008 1 commit
  26. 07 Jul, 2008 1 commit
  27. 23 Feb, 2008 2 commits
    • Johannes Sixt's avatar
      start_command(), if .in/.out > 0, closes file descriptors, not the callers · c20181e3
      Johannes Sixt authored
      Callers of start_command() can set the members .in and .out of struct
      child_process to a value > 0 to specify that this descriptor is used as
      the stdin or stdout of the child process.
      Previously, if start_command() was successful, this descriptor was closed
      upon return. Here we now make sure that the descriptor is also closed in
      case of failures. All callers are updated not to close the file descriptor
      themselves after start_command() was called.
      Note that earlier run_gpg_verify() of git-verify-tag set .out = 1, which
      worked because start_command() treated this as a special case, but now
      this is incorrect because it closes the descriptor. The intent here is to
      inherit stdout to the child, which is achieved by .out = 0.
      Signed-off-by: default avatarJohannes Sixt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Johannes Sixt's avatar
      start_command(), .in/.out/.err = -1: Callers must close the file descriptor · e72ae288
      Johannes Sixt authored
      By setting .in, .out, or .err members of struct child_process to -1, the
      callers of start_command() can request that a pipe is allocated that talks
      to the child process and one end is returned by replacing -1 with the
      file descriptor.
      Previously, a flag was set (for .in and .out, but not .err) to signal
      finish_command() to close the pipe end that start_command() had handed out,
      so it was optional for callers to close the pipe, and many already do so.
      Now we make it mandatory to close the pipe.
      Signed-off-by: default avatarJohannes Sixt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  28. 18 Feb, 2008 1 commit
  29. 16 Jan, 2008 1 commit
  30. 10 Jan, 2008 1 commit
  31. 04 Jan, 2008 1 commit
  32. 08 Nov, 2007 1 commit
  33. 19 Sep, 2007 1 commit
  34. 13 Aug, 2007 1 commit
  35. 11 Aug, 2007 2 commits