1. 14 1月, 2014 8 次提交
  2. 11 1月, 2014 1 次提交
    • J
      mv: let 'git mv file no-such-dir/' error out on Windows, too · a8933469
      Johannes Sixt 提交于
      The previous commit c57f6281 (mv: let 'git mv file no-such-dir/' error out)
      relies on that rename("file", "no-such-dir/") fails if the directory does not
      exist (note the trailing slash).  This does not work as expected on Windows:
      This rename() call does not fail, but renames "file" to "no-such-dir" (not to
      "no-such-dir/file"). Insert an explicit check for this case to force an error.
      
      This changes the error message from
      
         $ git mv file no-such-dir/
         fatal: renaming 'file' failed: Not a directory
      
      to
      
         $ git mv file no-such-dir/
         fatal: destination directory does not exist, source=file, destination=no-such-dir/
      Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a8933469
  3. 07 1月, 2014 2 次提交
  4. 04 1月, 2014 1 次提交
  5. 03 1月, 2014 2 次提交
    • K
      gc: notice gc processes run by other users · ed7eda8b
      Kyle J. McKay 提交于
      Since 64a99eb4 git gc refuses to run without the --force option if
      another gc process on the same repository is already running.
      
      However, if the repository is shared and user A runs git gc on the
      repository and while that gc is still running user B runs git gc on
      the same repository the gc process run by user A will not be noticed
      and the gc run by user B will go ahead and run.
      
      The problem is that the kill(pid, 0) test fails with an EPERM error
      since user B is not allowed to signal processes owned by user A
      (unless user B is root).
      
      Update the test to recognize an EPERM error as meaning the process
      exists and another gc should not be run (unless --force is given).
      Signed-off-by: NKyle J. McKay <mackyle@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ed7eda8b
    • J
      Revert "prompt: clean up strbuf usage" · e1c1a324
      Jeff King 提交于
      This reverts commit 31b49d9b.
      
      That commit taught do_askpass to hand ownership of our
      buffer back to the caller rather than simply return a
      pointer into our internal strbuf.  What it failed to notice,
      though, was that our internal strbuf is static, because we
      are trying to emulate the getpass() interface.
      
      By handing off ownership, we created a memory leak that
      cannot be solved. Sometimes git_prompt returns a static
      buffer from getpass() (or our smarter git_terminal_prompt
      wrapper), and sometimes it returns an allocated string from
      do_askpass.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e1c1a324
  6. 31 12月, 2013 1 次提交
  7. 21 12月, 2013 1 次提交
  8. 18 12月, 2013 15 次提交
  9. 13 12月, 2013 2 次提交
    • J
      cat-file: handle --batch format with missing type/size · 6554dfa9
      Jeff King 提交于
      Commit 98e2092b taught cat-file to stream blobs with --batch,
      which requires that we look up the object type before
      loading it into memory.  As a result, we now print the
      object header from information in sha1_object_info, and the
      actual contents from the read_sha1_file. We double-check
      that the information we printed in the header matches the
      content we are about to show.
      
      Later, commit 93d2a607 allowed custom header lines for
      --batch, and commit 5b086407 made type lookups optional. As a
      result, specifying a header line without the type or size
      means that we will not look up those items at all.
      
      This causes our double-checking to erroneously die with an
      error; we think the type or size has changed, when in fact
      it was simply left at "0".
      
      For the size, we can fix this by only doing the consistency
      double-check when we have retrieved the size via
      sha1_object_info. In the case that we have not retrieved the
      value, that means we also did not print it, so there is
      nothing for us to check that we are consistent with.
      
      We could do the same for the type. However, besides our
      consistency check, we also care about the type in deciding
      whether to stream or not. So instead of handling the case
      where we do not know the type, this patch instead makes sure
      that we always trigger a type lookup when we are printing,
      so that even a format without the type will stream as we
      would in the normal case.
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6554dfa9
    • J
      cat-file: pass expand_data to print_object_or_die · 370c9268
      Jeff King 提交于
      We currently individually pass the sha1, type, and size
      fields calculated by sha1_object_info. However, if we pass
      the whole struct, the called function can make more
      intelligent decisions about which fields were actually
      filled by sha1_object_info.
      
      This patch takes that first refactoring step, passing the
      whole struct, so further patches can make those decisions
      with less noise in their diffs. There should be no
      functional change to this patch (aside from a minor typo fix
      in the error message).
      
      As a side effect, we can rename the local variables in the
      function to "type" and "size", since the names are no longer
      taken.
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      370c9268
  10. 10 12月, 2013 2 次提交
    • J
      rev-parse: be more careful with munging arguments · 62f162f8
      Jeff King 提交于
      When rev-parse looks at whether an argument like "foo..bar" or
      "foobar^@" is a difference or parent-shorthand, it internally
      munges the arguments so that it can pass the individual rev
      arguments to get_sha1(). However, we do not consistently un-munge
      the result.
      
      For cases where we do not match (e.g., "doesnotexist..HEAD"), we
      would then want to try to treat the argument as a filename.
      try_difference gets() this right, and always unmunges in this case.
      However, try_parent_shorthand() never unmunges, leading to incorrect
      error messages, or even incorrect results:
      
        $ git rev-parse foobar^@
        foobar
        fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
        Use '--' to separate paths from revisions, like this:
        'git <command> [<revision>...] -- [<file>...]'
      
        $ >foobar
        $ git rev-parse foobar^@
        foobar
      
      For cases where we do match, neither function unmunges. This does
      not currently matter, since we are done with the argument. However,
      a future patch will do further processing, and this prepares for
      it. In addition, it's simply a confusing interface for some cases to
      modify the const argument, and others not to.
      Signed-off-by: NJeff King <peff@peff.net>
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      62f162f8
    • J
      rev-parse: correctly diagnose revision errors before "--" · 14185673
      Jeff King 提交于
      Rev-parse understands that a "--" may separate revisions and
      filenames, and that anything after the "--" is taken as-is.
      However, it does not understand that anything before the
      token must be a revision (which is the usual rule
      implemented by the setup_revisions parser).
      
      Since rev-parse prefers revisions to files when parsing
      before the "--", we end up with the correct result (if such
      an argument is a revision, we parse it as one, and if it is
      not, it is an error either way).  However, we misdiagnose
      the errors:
      
        $ git rev-parse foobar -- >/dev/null
        fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
        Use '--' to separate paths from revisions, like this:
        'git <command> [<revision>...] -- [<file>...]'
      
        $ >foobar
        $ git rev-parse foobar -- >/dev/null
        fatal: bad flag '--' used after filename
      
      In both cases, we should know that the real error is that
      "foobar" is meant to be a revision, but could not be
      resolved.
      Signed-off-by: NJeff King <peff@peff.net>
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      14185673
  11. 05 12月, 2013 1 次提交
  12. 04 12月, 2013 2 次提交
  13. 03 12月, 2013 2 次提交