1. 31 8月, 2008 2 次提交
    • J
      git-apply: Loosen "match_beginning" logic · ed0f47a8
      Junio C Hamano 提交于
      Even after a handfle attempts, match_beginning logic still has corner
      cases:
      
          1bf1a859 (apply: treat EOF as proper context., 2006-05-23)
          65aadb92 (apply: force matching at the beginning., 2006-05-24)
          4be60962 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17)
          ee5a317e (Fix "git apply" to correctly enforce "match ..., 2008-04-06)
      
      This is a tricky piece of code.
      
      We still incorrectly enforce "match_beginning" for -U0 matches.
      I noticed this while trying out an example sequence from Clemens Buchacher:
      
          $ echo a >victim
          $ git add victim
          $ echo b >>victim
          $ git diff -U0 >patch
          $ cat patch
          diff --git i/victim w/victim
          index 7898192..422c2b7 100644
          --- i/victim
          +++ w/victim
          @@ -1,0 +2 @@ a
          +b
          $ git apply --cached --unidiff-zero <patch
          $ git show :victim
          b
          a
      
      The change inserts a new line before the second line, but we insist it to
      be applied at the beginning.  As the result, the code refuses to apply it
      at the original offset, and we end up adding the line at the beginning.
      
      Updates to the test script are by Clemens Buchacher.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ed0f47a8
    • J
      Fix example in git-name-rev documentation · ee837244
      Junio C Hamano 提交于
      Since 59d3f541 (name-rev: avoid "^0" when unneeded, 2007-02-20), name-rev
      stopped showing an unnecessary "^0" to dereference a tag down to a commit.
      The patch should have made a matching update to the documentation, but we
      forgot.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ee837244
  2. 30 8月, 2008 5 次提交
  3. 29 8月, 2008 6 次提交
  4. 28 8月, 2008 2 次提交
  5. 27 8月, 2008 3 次提交
  6. 26 8月, 2008 1 次提交
    • A
      Makefile: always provide a fallback when hardlinks fail · 3e073dc5
      Andreas Färber 提交于
      We make hardlinks from "git" to "git-<cmd>" built-ins and have been
      careful to avoid cross-device links when linking "git-<cmd>" to
      gitexecdir.
      
      However, we were not prepared to deal with a build directory that is
      incapable of making hard links within itself. This patch corrects it.
      
      Instead of temporarily linking "git" to gitexecdir, directly link "git-
      add", falling back to "cp". Try hardlinking that as "git-<cmd>", falling
      back to symlinks or "cp" on error.
      
      While at it, avoid 100+ error messages from hardlink failures when we are
      going to fall back to symlinks or "cp" by redirecting the standard error
      to /dev/null.
      Signed-off-by: NAndreas Färber <andreas.faerber@web.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3e073dc5
  7. 25 8月, 2008 7 次提交
  8. 24 8月, 2008 4 次提交
    • A
      Respect core.autocrlf in combined diff · 5e568f9e
      Alexander Gavrilov 提交于
      Fix git-diff to make it produce useful 3-way diffs for merge conflicts in
      repositories with autocrlf enabled. Otherwise it always reports that the
      whole file was changed, because it uses the contents from the working tree
      without necessary conversion.
      Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5e568f9e
    • M
      Makefile: enable SNPRINTF_RETURNS_BOGUS for HP-UX · 7d770163
      Miklos Vajna 提交于
      In 81cc66a5, customization has been added to Makefile for supporting
      HP-UX, but git commit is still problematic. This should fix the issue.
      Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
      Acked-by: NRobert Schiele <rschiele@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7d770163
    • J
      merge: fix numerus bugs around "trivial merge" area · 446247db
      Junio C Hamano 提交于
      The "trivial merge" codepath wants to optimize itself by making an
      internal call to the read-tree machinery, but it does not read the index
      before doing so, and the codepath is never exercised.  Incidentally, this
      failure to read the index upfront means that the safety to refuse doing
      anything when the index is unmerged does not kick in, either.
      
      These two problem are fixed by using read_cache_unmerged() that does read
      the index before checking if it is unmerged at the beginning of
      cmd_merge().
      
      The primary logic of the merge, however, assumes that the process never
      reads the index in-core, and the call to write_cache_as_tree() it makes
      from write_tree_trivial() will always read from the on-disk index that is
      prepared the strategy back-ends.  This assumption is now broken by the
      above fix.  To fix this issue, we now call discard_cache() before calling
      write_tree_trivial() when it wants to write the on-disk index as a tree.
      
      When multiple strategies are tried, their results are evaluated by reading
      the resulting index and inspecting it.  The codepath needs to make a call
      to read_cache() for each successful strategy, and for that to work, they
      need to discard_cache() the one read by the previous round.
      
      Also the "trivial merge" forgot that the current commit is one of the
      parents of the resulting commit.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      446247db
    • J
      unpack_trees(): protect the handcrafted in-core index from read_cache() · 913e0e99
      Junio C Hamano 提交于
      unpack_trees() rebuilds the in-core index from scratch by allocating a new
      structure and finishing it off by copying the built one to the final
      index.
      
      The resulting in-core index is Ok for most use, but read_cache() does not
      recognize it as such.  The function is meant to be no-op if you already
      have loaded the index, until you call discard_cache().
      
      This change the way read_cache() detects an already initialized in-core
      index, by introducing an extra bit, and marks the handcrafted in-core
      index as initialized, to avoid this problem.
      
      A better fix in the longer term would be to change the read_cache() API so
      that it will always discard and re-read from the on-disk index to avoid
      confusion.  But there are higher level API that have relied on the current
      semantics, and they and their users all need to get converted, which is
      outside the scope of 'maint' track.
      
      An example of such a higher level API is write_cache_as_tree(), which is
      used by git-write-tree as well as later Porcelains like git-merge, revert
      and cherry-pick.  In the longer term, we should remove read_cache() from
      there and add one to cmd_write_tree(); other callers expect that the
      in-core index they prepared is what gets written as a tree so no other
      change is necessary for this particular codepath.
      
      The original version of this patch marked the index by pointing an
      otherwise wasted malloc'ed memory with o->result.alloc, but this version
      uses Linus's idea to use a new "initialized" bit, which is conceptually
      much cleaner.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      913e0e99
  9. 23 8月, 2008 3 次提交
  10. 22 8月, 2008 1 次提交
  11. 21 8月, 2008 6 次提交