1. 23 Feb, 2016 1 commit
    • Jeff King's avatar
      merge-tree: drop generate_common strategy · b779b3a1
      Jeff King authored
      When merge_blobs sees an add/add conflict, it tries to
      create a virtual base object for the 3-way merge that
      consists of the common lines of each file. It inherited this
      strategy from merge-one-file in 0c799383 (Improved three-way
      blob merging code, 2006-06-28), and the point is to minimize
      the size of the conflict hunks. That commit talks about "if
      libxdiff were to ever grow a compatible three-way merge, it
      could probably be directly plugged in".
      That has long since happened. So as with merge-one-file in
      the previous commit, this extra step is no longer necessary.
      Our 3-way merge code is smart enough to do the minimizing
      itself if we simply feed it an empty base, which is what the
      more modern merge-recursive strategy already does.
      Not only does this let us drop some code, but it removes an
      overflow bug in generate_common_file(). We allocate a buffer
      as large as the smallest of the two blobs, under the
      assumption that there cannot be more common content than
      what is in the smaller blob. However, xdiff may feed us
      more: if neither file ends in a newline, it feeds us the
      "\nNo newline at end of file" marker as common content, and
      we write it into the output. If the differences between the
      files are small than that string, we overflow the output
      buffer.  This patch solves it by simply dropping the buggy
      code entirely.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 20 Nov, 2015 2 commits
  3. 23 Mar, 2015 1 commit
  4. 10 Dec, 2012 1 commit
    • Junio C Hamano's avatar
      Which merge_file() function do you mean? · fa2364ec
      Junio C Hamano authored
      There are two different static functions and one global function,
      all of them called "merge_file()", with different signatures and
      purposes.  Rename them all to reduce confusion in "git grep" output:
       * Rename the static one in merge-index to "merge_one_path(const char
         *path)" as that function is about asking an external command to
         resolve conflicts in one path.
       * Rename the global one in merge-file.c that is only used by
         merge-tree to "merge_blobs()", as the function takes three blobs and
         returns the merged result only in-core, without doing anything to
         the filesystem.
       * Rename the one in merge-recursive to "merge_one_file()", just to be
      Also rename merge-file.[ch] to merge-blobs.[ch].
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 11 Apr, 2011 1 commit
  6. 26 Aug, 2010 1 commit
  7. 02 May, 2010 1 commit
    • René Scharfe's avatar
      git diff too slow for a file · 582aa00b
      René Scharfe authored
      Ever since the xdiff library had been introduced to git, all its callers
      have used the flag XDF_NEED_MINIMAL.  It makes sure that the smallest
      possible diff is produced, but that takes quite some time if there are
      lots of differences that can be expressed in multiple ways.
      This flag makes a difference for only 0.1% of the non-merge commits in
      the git repo of Linux, both in terms of diff size and execution time.
      The patches there are mostly nice and small.
      SungHyun Nam however reported a case in a different repo where a diff
      took more than 20 times longer to generate with XDF_NEED_MINIMAL than
      without.  Rebasing became really slow.
      This patch removes this flag from all callers.  The default of xdiff is
      saner because it has minimal to no impact in the normal case of small
      diffs and doesn't incur that much of a speed penalty for large ones.
      A follow-up patch may introduce a command line option to set the flag if
      the user needs it, similar to GNU diff's -d/--minimal.
      Signed-off-by: default avatarRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 21 Mar, 2010 2 commits
  9. 17 Jan, 2010 2 commits
  10. 25 Oct, 2008 1 commit
  11. 14 Dec, 2007 1 commit
  12. 06 Jul, 2007 1 commit
  13. 27 Feb, 2007 1 commit
    • Nicolas Pitre's avatar
      convert object type handling from a string to a number · 21666f1a
      Nicolas Pitre authored
      We currently have two parallel notation for dealing with object types
      in the code: a string and a numerical value.  One of them is obviously
      redundent, and the most used one requires more stack space and a bunch
      of strcmp() all over the place.
      This is an initial step for the removal of the version using a char array
      found in object reading code paths.  The patch is unfortunately large but
      there is no sane way to split it in smaller parts without breaking the
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
  14. 13 Dec, 2006 1 commit
  15. 02 Sep, 2006 1 commit
    • Shawn Pearce's avatar
      Replace uses of strdup with xstrdup. · 9befac47
      Shawn Pearce authored
      Like xmalloc and xrealloc xstrdup dies with a useful message if
      the native strdup() implementation returns NULL rather than a
      valid pointer.
      I just tried to use xstrdup in new code and found it to be missing.
      However I expected it to be present as xmalloc and xrealloc are
      already commonly used throughout the code.
      [jc: removed the part that deals with last_XXX, which I am
       finding more and more dubious these days.]
      Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
  16. 29 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Improved three-way blob merging code · 0c799383
      Linus Torvalds authored
      This fleshes out the code that generates a three-way merge of a set of
      It still actually does the three-way merge using an external executable
      (ie just calling "merge"), but the interfaces have been cleaned up a lot
      and are now fully based on the 'mmfile_t' interface, so if libxdiff were
      to ever grow a compatible three-way-merge, it could probably be directly
      plugged in.
      It also uses the previous XDL_EMIT_COMMON functionality extension to
      libxdiff to generate a made-up base file for the merge for the case where
      no base file previously existed. This should be equivalent to what we
      currently do in git-merge-one-file.sh:
      	diff -u -La/$orig -Lb/$orig $orig $src2 | git-apply --no-add
      except it should be much simpler and can be done using the direct libxdiff
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>