1. 23 Jan, 2013 1 commit
  2. 12 Sep, 2012 1 commit
    • Junio C Hamano's avatar
      ll-merge: warn about inability to merge binary files only when we can't · e0e2065f
      Junio C Hamano authored
      When a path being merged is auto detected to be a binary file, we
      warned "Cannot merge binary files" before switching to activate the
      binary ll-merge driver.  When we are merging with the -Xours/theirs
      option, however, we know what the "clean" merge result is, and the
      warning is inappropriate.
      
      In addition, when the path is explicitly marked as a binary file,
      this warning was not issued, even though without -Xours/theirs, we
      cannot cleanly automerge such a path, which was inconsistent.
      
      Move the warning code from ll_xdl_merge() to ll_binary_merge(), and
      issue the message only when we cannot cleanly automerge.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e0e2065f
  3. 09 Sep, 2012 1 commit
    • Junio C Hamano's avatar
      merge: teach -Xours/-Xtheirs to binary ll-merge driver · a944af1d
      Junio C Hamano authored
      The (discouraged) -Xours/-Xtheirs modes of merge are supposed to
      give a quick and dirty way to come up with a random mixture of
      cleanly merged parts and punted conflict resolution to take contents
      from one side in conflicting parts.  These options however were only
      passed down to the low level merge driver for text.
      
      Teach the built-in binary merge driver to notice them as well.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a944af1d
  4. 30 Apr, 2012 1 commit
  5. 04 Aug, 2011 1 commit
  6. 16 Jan, 2011 1 commit
  7. 26 Aug, 2010 2 commits
  8. 06 Aug, 2010 2 commits
  9. 02 Jul, 2010 1 commit
    • Eyvind Bernhardsen's avatar
      Avoid conflicts when merging branches with mixed normalization · f217f0e8
      Eyvind Bernhardsen authored
      Currently, merging across changes in line ending normalization is
      painful since files containing CRLF will conflict with normalized files,
      even if the only difference between the two versions is the line
      endings.  Additionally, any "real" merge conflicts that exist are
      obscured because every line in the file has a conflict.
      
      Assume you start out with a repo that has a lot of text files with CRLF
      checked in (A):
      
            o---C
           /     \
          A---B---D
      
      B: Add "* text=auto" to .gitattributes and normalize all files to
         LF-only
      
      C: Modify some of the text files
      
      D: Try to merge C
      
      You will get a ridiculous number of LF/CRLF conflicts when trying to
      merge C into D, since the repository contents for C are "wrong" wrt the
      new .gitattributes file.
      
      Fix ll-merge so that the "base", "theirs" and "ours" stages are passed
      through convert_to_worktree() and convert_to_git() before a three-way
      merge.  This ensures that all three stages are normalized in the same
      way, removing from consideration differences that are only due to
      normalization.
      
      This feature is optional for now since it changes a low-level mechanism
      and is not necessary for the majority of users.  The "merge.renormalize"
      config variable enables it.
      Signed-off-by: default avatarEyvind Bernhardsen <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f217f0e8
  10. 31 May, 2010 1 commit
    • Gary V. Vaughan's avatar
      Rewrite dynamic structure initializations to runtime assignment · 66dbfd55
      Gary V. Vaughan authored
      Unfortunately, there are still plenty of production systems with
      vendor compilers that choke unless all compound declarations can be
      determined statically at compile time, for example hpux10.20 (I can
      provide a comprehensive list of our supported platforms that exhibit
      this problem if necessary).
      
      This patch simply breaks apart any compound declarations with dynamic
      initialisation expressions, and moves the initialisation until after
      the last declaration in the same block, in all the places necessary to
      have the offending compilers accept the code.
      Signed-off-by: default avatarGary V. Vaughan <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      66dbfd55
  11. 21 Mar, 2010 2 commits
  12. 02 Mar, 2010 2 commits
  13. 18 Jan, 2010 1 commit
  14. 17 Jan, 2010 4 commits
  15. 06 Jan, 2010 1 commit
  16. 05 Jul, 2009 1 commit
    • Johannes Sixt's avatar
      run_command: return exit code as positive value · 5709e036
      Johannes Sixt authored
      As a general guideline, functions in git's code return zero to indicate
      success and negative values to indicate failure. The run_command family of
      functions followed this guideline. But there are actually two different
      kinds of failure:
      
      - failures of system calls;
      
      - non-zero exit code of the program that was run.
      
      Usually, a non-zero exit code of the program is a failure and means a
      failure to the caller. Except that sometimes it does not. For example, the
      exit code of merge programs (e.g. external merge drivers) conveys
      information about how the merge failed, and not all exit calls are
      actually failures.
      
      Furthermore, the return value of run_command is sometimes used as exit
      code by the caller.
      
      This change arranges that the exit code of the program is returned as a
      positive value, which can now be regarded as the "result" of the function.
      System call failures continue to be reported as negative values.
      Signed-off-by: default avatarJohannes Sixt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5709e036
  17. 02 Jul, 2009 1 commit
  18. 27 Jun, 2009 1 commit
    • Thomas Rast's avatar
      Use die_errno() instead of die() when checking syscalls · 0721c314
      Thomas Rast authored
      Lots of die() calls did not actually report the kind of error, which
      can leave the user confused as to the real problem.  Use die_errno()
      where we check a system/library call that sets errno on failure, or
      one of the following that wrap such calls:
      
        Function              Passes on error from
        --------              --------------------
        odb_pack_keep         open
        read_ancestry         fopen
        read_in_full          xread
        strbuf_read           xread
        strbuf_read_file      open or strbuf_read_file
        strbuf_readlink       readlink
        write_in_full         xwrite
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0721c314
  19. 14 Jun, 2009 1 commit
  20. 09 Jun, 2009 1 commit
  21. 30 Apr, 2009 1 commit
    • Alex Riesen's avatar
      replace direct calls to unlink(2) with unlink_or_warn · 691f1a28
      Alex Riesen authored
      This helps to notice when something's going wrong, especially on
      systems which lock open files.
      
      I used the following criteria when selecting the code for replacement:
      - it was already printing a warning for the unlink failures
      - it is in a function which already printing something or is
        called from such a function
      - it is in a static function, returning void and the function is only
        called from a builtin main function (cmd_)
      - it is in a function which handles emergency exit (signal handlers)
      - it is in a function which is obvously cleaning up the lockfiles
      Signed-off-by: default avatarAlex Riesen <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      691f1a28
  22. 24 Nov, 2008 1 commit
  23. 31 Aug, 2008 1 commit
  24. 14 May, 2008 1 commit
  25. 18 Feb, 2008 1 commit