1. 29 8月, 2008 1 次提交
  2. 28 8月, 2008 2 次提交
  3. 27 8月, 2008 3 次提交
  4. 25 8月, 2008 7 次提交
  5. 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
  6. 23 8月, 2008 2 次提交
  7. 22 8月, 2008 1 次提交
  8. 21 8月, 2008 11 次提交
  9. 20 8月, 2008 3 次提交
  10. 19 8月, 2008 3 次提交
  11. 18 8月, 2008 3 次提交