1. 30 6月, 2008 1 次提交
    • J
      fetch: give a hint to the user when local refs fail to update · f3cb169b
      Jeff King 提交于
      There are basically two categories of update failures for
      local refs:
      
        1. problems outside of git, like disk full, bad
           permissions, etc.
      
        2. D/F conflicts on tracking branch ref names
      
      In either case, there should already have been an error
      message. In case '1', hopefully enough information has
      already been given that the user can fix it. In the case of
      '2', we can hint that the user can clean up their tracking
      branch area by using 'git remote prune'.
      
      Note that we don't actually know _which_ case we have, so
      the user will receive the hint in case 1, as well. In this
      case the suggestion won't do any good, but hopefully the
      user is smart enough to figure out that it's just a hint.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f3cb169b
  2. 28 6月, 2008 1 次提交
    • J
      fetch: report local storage errors in status table · 6315472e
      Jeff King 提交于
      Previously, if there was an error while storing a local
      tracking ref, the low-level functions would report an error,
      but fetch's status output wouldn't indicate any problem.
      E.g., imagine you have an old "refs/remotes/origin/foo/bar" but
      upstream has deleted "foo/bar" in favor of a new branch
      "foo". You would get output like this:
      
        error: there are still refs under 'refs/remotes/origin/foo'
        From $url_of_repo
         * [new branch]      foo        -> origin/foo
      
      With this patch, the output takes into account the status of
      updating the local ref:
      
        error: there are still refs under 'refs/remotes/origin/foo'
        From $url_of_repo
         ! [new branch]      foo        -> origin/foo  (unable to update local ref)
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6315472e
  3. 27 6月, 2008 6 次提交
  4. 26 6月, 2008 7 次提交
  5. 24 6月, 2008 2 次提交
    • J
      git-svn: make rebuild respect rewriteRoot option · 74b1e123
      Jan Krüger 提交于
      Suppose someone fetches git-svn-ified commits from another repo and then
      attempts to use 'git-svn init --rewrite-root=foo bar'. Using git svn rebase
      after that will fail badly:
      
       * For each commit tried by working_head_info, rebuild is called indirectly.
       * rebuild will iterate over all commits and skip all of them because the
         URL does not match. Because of that no rev_map file is generated at all.
       * Thus, rebuild will run once for every commit. This takes ages.
       * In the end there still isn't any rev_map file and thus working_head_info
         fails.
      
      Addressing this behaviour fixes an apparently not too uncommon problem with
      providing git-svn mirrors of Subversion repositories. Some repositories are
      accessed using different URLs depending on whether the user has push
      privileges or not. In the latter case, an anonymous URL is often used that
      differs from the push URL. Providing a mirror that is usable in both cases
      becomes a lot more possible with this change.
      Signed-off-by: NJan Krüger <jk@jk.gs>
      Acked-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      74b1e123
    • P
      Workaround for AIX mkstemp() · 6ff6af62
      Patrick Higgins 提交于
      The AIX mkstemp will modify it's template parameter to an empty string if
      the call fails. This caused a subsequent mkdir to fail.
      Signed-off-by: NPatrick Higgins <patrick.higgins@cexp.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6ff6af62
  6. 23 6月, 2008 5 次提交
  7. 20 6月, 2008 5 次提交
    • L
      Make git_dir a path relative to work_tree in setup_work_tree() · 044bbbcb
      Linus Torvalds 提交于
      Once we find the absolute paths for git_dir and work_tree, we can make
      git_dir a relative path since we know pwd will be work_tree. This should
      save the kernel some time traversing the path to work_tree all the time
      if git_dir is inside work_tree.
      
      Daniel's patch didn't apply for me as-is, so I recreated it with some
      differences, and here are the numbers from ten runs each.
      
      There is some IO for me - probably due to more-or-less random flushing of
      the journal - so the variation is bigger than I'd like, but whatever:
      
      	Before:
      		real    0m8.135s
      		real    0m7.933s
      		real    0m8.080s
      		real    0m7.954s
      		real    0m7.949s
      		real    0m8.112s
      		real    0m7.934s
      		real    0m8.059s
      		real    0m7.979s
      		real    0m8.038s
      
      	After:
      		real    0m7.685s
      		real    0m7.968s
      		real    0m7.703s
      		real    0m7.850s
      		real    0m7.995s
      		real    0m7.817s
      		real    0m7.963s
      		real    0m7.955s
      		real    0m7.848s
      		real    0m7.969s
      
      Now, going by "best of ten" (on the assumption that the longer numbers
      are all due to IO), I'm saying a 7.933s -> 7.685s reduction, and it does
      seem to be outside of the noise (ie the "after" case never broke 8s, while
      the "before" case did so half the time).
      
      So looks like about 3% to me.
      
      Doing it for a slightly smaller test-case (just the "arch" subdirectory)
      gets more stable numbers probably due to not filling the journal with
      metadata updates, so we have:
      
      	Before:
      		real    0m1.633s
      		real    0m1.633s
      		real    0m1.633s
      		real    0m1.632s
      		real    0m1.632s
      		real    0m1.630s
      		real    0m1.634s
      		real    0m1.631s
      		real    0m1.632s
      		real    0m1.632s
      
      	After:
      		real    0m1.610s
      		real    0m1.609s
      		real    0m1.610s
      		real    0m1.608s
      		real    0m1.607s
      		real    0m1.610s
      		real    0m1.609s
      		real    0m1.611s
      		real    0m1.608s
      		real    0m1.611s
      
      where I'ld just take the averages and say 1.632 vs 1.610, which is just
      over 1% peformance improvement.
      
      So it's not in the noise, but it's not as big as I initially thought and
      measured.
      
      (That said, it obviously depends on how deep the working directory path is
      too, and whether it is behind NFS or something else that might need to
      cause more work to look up).
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      044bbbcb
    • J
      Documentation: fix formatting in git-svn · 3b2bbe9b
      Jan Krüger 提交于
      Due to a misplaced list block separator, general hints about the config
      file options got indented at the same level as the description of the last
      option, making it easy to miss them.
      Signed-off-by: NJan Krüger <jk@jk.gs>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3b2bbe9b
    • B
      t7502-commit.sh: test_must_fail doesn't work with inline environment variables · e2007832
      Brandon Casey 提交于
      When the arguments to test_must_fail() begin with a variable assignment,
      test_must_fail() attempts to execute the variable assignment as a command.
      This fails, and so test_must_fail returns with a successful status value
      without running the command it was intended to test.
      
      For example, the following script:
      
      	#!/bin/sh
      	test_must_fail () {
      		"$@"
      		test $? -gt 0 -a $? -le 129
      	}
      	foo='wo adrian'
      	test_must_fail foo='yo adrian' sh -c 'echo foo: $foo'
      
      always exits zero and prints the message:
      
      	test.sh: line 3: foo=yo adrian: command not found
      
      Test 16 calls test_must_fail in such a way and therefore has not been
      testing whether git 'do[es] not fire editor in the presence of conflicts'.
      
      A workaround is to set and export the variable in a normal way, not
      using one-shot notation.  Because this would affect the remainder of
      the process, the test is done inside a subshell.
      Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e2007832
    • D
      20827d99
    • B
  8. 19 6月, 2008 3 次提交
    • J
      diff -c/--cc: do not include uninteresting deletion before leading context · c86fbe53
      Junio C Hamano 提交于
      When we include a few uninteresting lines before the interesting ones as
      context, we are only interested in seeing the surviving lines themselves
      and not the deleted lines that are before them.  Mark the added leading
      context lines in give_context() and not show deleted lines form them.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c86fbe53
    • J
      GIT 1.5.6 · e449f105
      Junio C Hamano 提交于
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e449f105
    • J
      clean up error conventions of remote.c:match_explicit · 9a7bbd1d
      Jeff King 提交于
      match_explicit is called for each push refspec to try to
      fully resolve the source and destination sides of the
      refspec.  Currently, we look at each refspec and report
      errors on both the source and the dest side before aborting.
      
      It makes sense to report errors for each refspec, since an
      error in one is independent of an error in the other.
      However, reporting errors on the 'dst' side of a refspec if
      there has been an error on the 'src' side does not
      necessarily make sense, since the interpretation of the
      'dst' side depends on the 'src' side (for example, when
      creating a new unqualified remote ref, we use the same type
      as the src ref).
      
      This patch lets match_explicit return early when the src
      side of the refspec is bogus. We still look at all of the
      refspecs before aborting the push, though.
      
      At the same time, we clean up the call signature, which
      previously took an extra "errs" flag. This was pointless, as
      we didn't act on that flag, but rather just passed it back
      to the caller. Instead, we now use the more traditional
      "return -1" to signal an error, and the caller aggregates
      the error count.
      
      This change fixes two bugs, as well:
      
        - the early return avoids a segfault when passing a NULL
          matched_src to guess_ref()
      
        - the check for multiple sources pointing to a single dest
          aborted if the "err" flag was set. Presumably the intent
          was not to bother with the check if we had no
          matched_src. However, since the err flag was passed in
          from the caller, we might abort the check just because a
          previous refspec had a problem, which doesn't make
          sense.
      
          In practice, this didn't matter, since due to the error
          flag we end up aborting the push anyway.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9a7bbd1d
  9. 18 6月, 2008 5 次提交
  10. 17 6月, 2008 5 次提交