1. 13 11月, 2010 1 次提交
    • N
      add: do not rely on dtype being NULL behavior · 0188f6b3
      Nguyễn Thái Ngọc Duy 提交于
      Commit c84de707 (excluded_1(): support exclude files in index -
      2009-08-20) added support for excluded() where dtype can be NULL. It
      was designed specifically for index matching because there was no
      other way to extract dtype information from index. It did not support
      wildcard matching (for example, "a*/" pattern would fail to match).
      
      The code was probably misread when commit 108da0db (git add: Add the
      "--ignore-missing" option for the dry run - 2010-07-10) was made
      because DT_UNKNOWN happens to be zero (NULL) too.
      
      Do not pass DT_UNKNOWN/NULL to excluded(), instead pass a pointer to a
      variable that contains DT_UNKNOWN. The real dtype will be extracted
      from worktree by excluded(), as expected.
      Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0188f6b3
  2. 09 10月, 2010 4 次提交
  3. 07 10月, 2010 2 次提交
  4. 01 10月, 2010 1 次提交
  5. 28 9月, 2010 1 次提交
  6. 13 9月, 2010 1 次提交
  7. 10 9月, 2010 1 次提交
  8. 08 9月, 2010 1 次提交
    • J
      fast-export: ensure that a renamed file is printed after all references · 4ce6fb80
      Johannes Sixt 提交于
      t9350 sets up a commit where a file is both copied and renamed. The output
      of fast-export for this commit should look like this:
      
        author ...
        committer ...
        from :19
        C "file2" "file4"
        R "file2" "file5"
      
      The order of the two modification lines is derived from the result that
      the diff machinery produces.
      
      060df624 (fast-export: Fix output order of D/F changes) inserted a qsort
      call that modifies the order of the diff result. Unfortunately, qsort need
      not be stable. Therefore, it is possible that the 'R' line appears before
      the 'C' line and the resulting fast-import stream is incorrect.
      
      Fix it by forcing that the rename entry is printed after all other
      modification lines with the same file name.
      Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4ce6fb80
  9. 07 9月, 2010 2 次提交
  10. 04 9月, 2010 4 次提交
  11. 01 9月, 2010 1 次提交
  12. 30 8月, 2010 2 次提交
  13. 27 8月, 2010 1 次提交
  14. 26 8月, 2010 3 次提交
    • B
      builtin/fetch.c: ignore merge config when not fetching from branch's remote · 3ee1757b
      Brandon Casey 提交于
      When 'git fetch' is supplied a single argument, it tries to match it
      against a configured remote and then fetch the refs specified by the
      named remote's fetchspec.  Additionally, or alternatively, if the current
      branch has a merge ref configured, and if the name of the remote supplied
      to fetch matches the one in the branch's configuration, then git also adds
      the merge ref to the list of refs to update.
      
      If the argument to fetch does not specify a named remote, or if the name
      supplied does not match the remote configured for the current branch, then
      the current branch's merge configuration should not be considered.
      
      git currently mishandles the case when the argument to fetch specifies a
      GIT URL(i.e. not a named remote) and the current branch has a configured
      merge ref.  In this case, fetch should ignore the branch's merge ref and
      attempt to fetch from the remote repository's HEAD branch.  But, since
      fetch only checks _whether_ the current branch has a merge ref configured,
      and does _not_ check whether the branch's configured remote matches the
      command line argument (until later), it will mistakenly enter the wrong
      branch of an 'if' statement and will not fall back to fetch the HEAD branch.
      The fetch ends up doing nothing and returns with a successful zero status.
      
      Fix this by comparing the remote repository's name to the branch's remote
      name, in addition to whether it has a configured merge ref, sooner, so that
      fetch can correctly decide whether the branch's configuration is interesting
      or not, and fall back to fetching from the remote's HEAD branch when
      appropriate.
      
      This fixes the test in t5510.
      Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3ee1757b
    • J
      checkout: respect diff.ignoreSubmodules setting · 175f6e59
      Johannes Schindelin 提交于
      When 'git checkout' reports uncommitted changes, it also does so for
      submodules.
      
      The default mode is now to look really hard into submodules, not only
      for different commits, but also for modified files. Since this can be
      pretty expensive when there are a lot (and large) submodules, there is
      the diff.ignoreSubmodules option.
      
      Let's respect that setting when 'git checkout' reports the uncommitted
      changes, since it does nothing else than a 'git diff --name-status'.
      Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      175f6e59
    • L
      Fix 'git log' early pager startup error case · 1fda91b5
      Linus Torvalds 提交于
      We start the pager too early for several git commands, which results in
      the errors sometimes going to the pager rather than show up as errors.
      
      This is often hidden by the fact that we pass in '-X' to less by default,
      which causes 'less' to exit for small output, but if you do
      
        export LESS=-S
      
      you can then clearly see the problem by doing
      
        git log --prretty
      
      which shows the error message ("fatal: unrecognized argument: --prretty")
      being sent to the pager.
      
      This happens for pretty much all git commands that use USE_PAGER, and then
      check arguments separately. But "git diff" does it too early too (even
      though it does an explicit setup_pager() call)
      
      This only fixes it for the trivial "git log" family case.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1fda91b5
  15. 25 8月, 2010 1 次提交
  16. 23 8月, 2010 1 次提交
  17. 22 8月, 2010 3 次提交
    • Æ
      reset: suggest what to do upon "git reset --mixed <paths>" · a4941a81
      Ævar Arnfjörð Bjarmason 提交于
      When you call "git reset --mixed <paths>" git will warn that using mixed
      with paths is deprecated:
      
          warning: --mixed option is deprecated with paths.
      
      That doesn't tell the user what he should use instead. Expand on the
      warning and tell the user to just omit --mixed:
      
          warning: --mixed with paths is deprecated; use 'git reset -- <paths>' instead
      
      The exact wording of the warning was suggested by Jonathan Nieder.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a4941a81
    • J
      apply: handle traditional patches with space in filename · 5a12c886
      Jonathan Nieder 提交于
      To discover filenames from the --- and +++ lines in a traditional
      unified diff, currently "git apply" scans forward for a whitespace
      character on each line and stops there.  It can't use the whole line
      because "diff -u" likes to include timestamps, like so:
      
       --- foo	2000-07-12 16:56:50.020000414 -0500
       +++ bar	2010-07-12 16:56:50.020000414 -0500
      
      The whitespace-seeking heuristic works great, even when the tab
      has been converted to spaces by some email + copy-and-paste
      related corruption.
      
      Except for one problem: if the filename itself contains whitespace,
      the inferred filename will be too short.
      
      When Giuseppe ran into this problem, it was for a file creation
      patch (for debian/licenses/LICENSE.global BSD-style Chromium).
      So one can't use the list of files present in the index to deduce an
      appropriate filename (not to mention that way lies madness; see
      v0.99~402, 2005-05-31).
      
      Instead, look for a timestamp and use that if present to mark the end
      of the filename.  If no timestamp is present, the old heuristic is
      used, with one exception: the space character \040 is not considered
      terminating whitespace any more unless it is followed by a timestamp.
      Reported-by: NGiuseppe Iuculano <iuculano@debian.org>
      Acked-by: NGuido Günther <agx@sigxcpu.org>
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5a12c886
    • J
      apply: split quoted filename handling into new function · bb7306b5
      Jonathan Nieder 提交于
      The new find_name_gnu() function handles new-style '--- "a/foo"'
      patch header lines, leaving find_name() itself a bit less
      daunting.
      
      Functional change: do not clobber the p-value when there are not
      enough path components in a quoted file name to honor it.
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bb7306b5
  18. 21 8月, 2010 1 次提交
  19. 19 8月, 2010 4 次提交
  20. 16 8月, 2010 5 次提交