1. 02 May, 2018 1 commit
  2. 07 Aug, 2017 1 commit
  3. 23 Feb, 2016 1 commit
    • Jeff King's avatar
      merge-one-file: use empty blob for add/add base · 1a92e53b
      Jeff King authored
      When we see an add/add conflict on a file, we generate the
      conflicted content by doing a 3-way merge with a "virtual"
      base consisting of the common lines of the two sides. This
      strategy dates back to cb93c193 (merge-one-file: use common
      as base, instead of emptiness., 2005-11-09).
      
      Back then, the next step was to call rcs merge to generate
      the 3-way conflicts. Using the virtual base produced much
      better results, as rcs merge does not attempt to minimize
      the hunks. As a result, you'd get a conflict with the
      entirety of the files on either side.
      
      Since then, though, we've switched to using git-merge-file,
      which uses xdiff's "zealous" merge. This will find the
      minimal hunks even with just the simple, empty base.
      
      Let's switch to using that empty base. It's simpler, more
      efficient, and reduces our dependencies (we no longer need a
      working diff binary). It's also how the merge-recursive
      strategy handles this same case.
      
      We can almost get rid of git-sh-setup's create_virtual_base,
      but we don't here, for two reasons:
      
        1. The functions in git-sh-setup are part of our public
           interface, so it's possible somebody is depending on
           it. We'd at least need to deprecate it first.
      
        2. It's also used by mergetool's p4merge driver. It's
           unknown whether its 3-way merge is as capable as git's;
           if not, then it is benefiting from the function.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1a92e53b
  4. 26 Oct, 2015 1 commit
    • Jeff King's avatar
      merge: detect delete/modechange conflict · 72fac66b
      Jeff King authored
      If one side deletes a file and the other changes its
      content, we notice and report a conflict. However, if
      instead of changing the content, we change only the mode,
      the merge does not notice (and the mode change is silently
      dropped).
      
      The trivial index merge notices the problem and correctly
      leaves the conflict in the index, but both merge-recursive
      and merge-one-file will silently resolve this in favor of
      the deletion.  In many cases that is a sane resolution, but
      we should be punting to the user whenever there is any
      question. So let's detect and treat this as a conflict (in
      both strategies).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      72fac66b
  5. 25 Mar, 2013 4 commits
  6. 13 Mar, 2013 1 commit
    • Kevin Bracey's avatar
      mergetools/p4merge: create a base if none available · 4549162e
      Kevin Bracey authored
      Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
      
         p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
      
      Commit 0a0ec7bd changed this to:
      
         p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
      
      to avoid the problem of being unable to save in some circumstances with
      similar inputs.
      
      Unfortunately this approach produces much worse results on differing
      inputs. P4Merge really regards the blank file as the base, and once you
      have just a couple of differences between the two branches you end up
      with one a massive full-file conflict. The 3-way diff is not readable,
      and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
      useful view.
      
      The original approach appears to have invoked special 2-way merge
      behaviour in P4Merge that occurs only if the base filename is "" or
      equal to the left input.  You get a good visual comparison, and it does
      not auto-resolve differences. (Normally if one branch matched the base,
      it would autoresolve to the other branch).
      
      But there appears to be no way of getting this 2-way behaviour and being
      able to reliably save. Having base==left appears to be triggering other
      assumptions. There are tricks the user can use to force the save icon
      on, but it's not intuitive.
      
      So we now follow a suggestion given in the original patch's discussion:
      generate a virtual base, consisting of the lines common to the two
      branches. This is the same as the technique used in resolve and octopus
      merges, so we relocate that code to a shared function.
      
      Note that if there are no differences at the same location, this
      technique can lead to automatic resolution without conflict, combining
      everything from the 2 files.  As with the other merges using this
      technique, we assume the user will inspect the result before saving.
      Signed-off-by: default avatarKevin Bracey <kevin@bracey.fi>
      Reviewed-by: David Aguilar's avatarDavid Aguilar <davvid@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4549162e
  7. 24 Feb, 2013 1 commit
  8. 06 Oct, 2011 1 commit
  9. 29 Apr, 2011 1 commit
    • Jeff King's avatar
      merge-one-file: fix broken merges with alternate work trees · 6aaeca90
      Jeff King authored
      The merge-one-file tool predates the invention of
      GIT_WORK_TREE. By the time GIT_WORK_TREE was invented, most
      people were using the merge-recursive strategy, which
      handles resolving internally. Therefore these features have
      had very little testing together.
      
      For the most part, merge-one-file just works with
      GIT_WORK_TREE; most of its heavy lifting is done by plumbing
      commands which do respect GIT_WORK_TREE properly. The one
      exception is a shell redirection which touches the worktree
      directly, writing results to the wrong place in the presence
      of a GIT_WORK_TREE variable.
      
      This means that merges won't even fail; they will silently
      produce incorrect results, throwing out the entire "theirs"
      side of files which need content-level merging!
      
      This patch makes merge-one-file chdir to the toplevel of the
      working tree (and exit if we don't have one). This most
      closely matches the assumption made by the original script
      (before separate work trees were invented), and matches what
      happens when the script is called as part of a merge
      strategy.
      
      While we're at it, we'll also error-check the call to cat.
      Merging a file in a subdirectory could in fact fail, as the
      redirection relies on the "checkout-index" call just prior
      to create leading directories. But we never noticed, since
      we ignored the error return from running cat.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6aaeca90
  10. 05 Jun, 2010 1 commit
  11. 31 May, 2010 1 commit
  12. 10 Nov, 2009 1 commit
  13. 09 May, 2009 1 commit
  14. 30 Apr, 2009 1 commit
  15. 19 Mar, 2008 1 commit
  16. 11 Dec, 2007 1 commit
    • Junio C Hamano's avatar
      Support a merge with conflicting gitlink change · ff72af00
      Junio C Hamano authored
      merge-recursive did not support merging trees that have conflicting
      changes in submodules they contain, and died.  Support it exactly the
      same way as how it handles conflicting symbolic link changes --- mark it
      as a conflict, take the tentative result from the current side, and
      letting the caller resolve the conflict, without dying in merge_file()
      function.
      
      Also reword the error message issued when merge_file() has to die
      because it sees a tree entry of type it does not support yet.
      
      [jc: fixed up initial draft by Finn Arne Gangstad]
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ff72af00
  17. 09 Jul, 2007 1 commit
  18. 03 Jul, 2007 1 commit
  19. 07 Jun, 2007 1 commit
    • Junio C Hamano's avatar
      War on whitespace · a6080a0a
      Junio C Hamano authored
      This uses "git-apply --whitespace=strip" to fix whitespace errors that have
      crept in to our source files over time.  There are a few files that need
      to have trailing whitespaces (most notably, test vectors).  The results
      still passes the test, and build result in Documentation/ area is unchanged.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a6080a0a
  20. 22 Dec, 2006 1 commit
  21. 28 Oct, 2006 1 commit
    • Junio C Hamano's avatar
      merge: loosen overcautious "working file will be lost" check. · ed93b449
      Junio C Hamano authored
      The three-way merge complained unconditionally when a path that
      does not exist in the index is involved in a merge when it
      existed in the working tree.  If we are merging an old version
      that had that path tracked, but the path is not tracked anymore,
      and if we are merging that old version in, the result will be
      that the path is not tracked.  In that case we should not
      complain.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      ed93b449
  22. 10 Jul, 2006 1 commit
  23. 13 Apr, 2006 1 commit
  24. 06 Jan, 2006 1 commit
  25. 07 Dec, 2005 1 commit
    • Junio C Hamano's avatar
      git-merge-one: new merge world order. · b539c5e8
      Junio C Hamano authored
      This does two things:
      
       - Use new --stage=2 option to create the working tree file with
         leading paths and correct permission bits using
         checkout-index, as before.
      
       - Make sure we do not confuse "merge" program when the file
         being merged has an unfortunate name, '-L'.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      b539c5e8
  26. 06 Dec, 2005 1 commit
    • Junio C Hamano's avatar
      git-merge-one-file: resurrect leading path creation. · be61db92
      Junio C Hamano authored
      Since we do not use git-update-index followed by
      git-checkout-index -u to create the half-merged file on
      conflicting case anymore, we need to make sure the leading
      directories are created here.
      
      Maybe a better solution would be to allow update-index to add to
      higher stage, and checkout-index to extract from such, but that
      is a change slightly bigger than I would like to have so close
      to 1.0, so this should do for now.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      be61db92
  27. 02 Dec, 2005 3 commits
  28. 30 Nov, 2005 1 commit
  29. 20 Nov, 2005 2 commits
  30. 12 Nov, 2005 3 commits
  31. 08 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Big tool rename. · 215a7ad1
      Junio C Hamano authored
      As promised, this is the "big tool rename" patch.  The primary differences
      since 0.99.6 are:
      
        (1) git-*-script are no more.  The commands installed do not
            have any such suffix so users do not have to remember if
            something is implemented as a shell script or not.
      
        (2) Many command names with 'cache' in them are renamed with
            'index' if that is what they mean.
      
      There are backward compatibility symblic links so that you and
      Porcelains can keep using the old names, but the backward
      compatibility support  is expected to be removed in the near
      future.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      215a7ad1
  32. 30 Aug, 2005 1 commit
    • Linus Torvalds's avatar
      [PATCH] Make "git resolve" less scary · cdcb0ed4
      Linus Torvalds authored
      When we resolve a merge between two branches, and it removes a file in the
      current branch, we notify the person doing the resolve with a big nice
      notice like
      
      	Removing xyzzy
      
      which is all well and good.
      
      HOWEVER, we also do this when the file was actually removed in the current
      branch, and we're merging with another branch that didn't have it removed
      (or, indeed, if the other branch _did_ have it removed, but the common
      parent was far enough back that the file still existed in there).
      
      And that just doesn't make sense. In that case we're not removing
      anything: the file didn't exist in the branch we're merging into in the
      first place. So the message just makes people nervous, and makes no sense.
      
      This has been around forever, but I never bothered to do anything about
      it.
      
      Until now.
      
      The trivial fix is to only talk about removing files if the file existed
      in the branch we're merging into, but will not exist in the result.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      cdcb0ed4