This project is mirrored from Updated .
  1. 01 Oct, 2010 1 commit
  2. 14 Dec, 2009 3 commits
  3. 25 Oct, 2009 1 commit
  4. 30 Jul, 2008 1 commit
    • Junio C Hamano's avatar
      git-merge-octopus: use (merge-base A (merge B C D E...)) for stepwise merge · c5dc9a28
      Junio C Hamano authored
      Suppose you have this topology, and you are trying to make an octopus
      across A, B and C (you are at C and merging A and B into your branch).
      The protoccol between "git merge" and merge strategies is for the former
      to pass common ancestor(s), '--' and then commits being merged.
      git-merge-octopus does not produce the final merge in one-go.  It
      iteratively produces pairwise merges.  So the first step might be to come
      up with a merge between B and C:
                    /                 :
                   /   o---o---o---B..(M)
                  /   /
      and for that, "1" is used as the merge base, not because it is the base
      across A, B and C but because it is the base between B and C.  For this
      merge, A does not matter.
      I drew M in parentheses and lines between B and C to it in dotted line
      because we actually do _not_ create a real commit --- the only thing we
      need is a tree object, in order to proceed to the next step.
      Then the final merge result is obtained by merging tree of (M) and A using
      their common ancestor.  For that, we _could_ still use "1" as the merge
      But if you imagine a case where you started from A and M, you would _not_
      pick "1" as the merge base; you would rather use "2" which is a better
      base for this merge.
      That is why git-merge-octopus ignores the merge base given by "merge" but
      computes its own.
      The comment at the end of git-merge-octopus talks about "merge reference
      commit", that we used to update it to common found in this round, and that
      that updating was pointless.  After the first round of merge to produce
      the tree for M (but without actually creating the commit object M itself),
      in order to figure out the merge base used to merge that with A in the
      second round, we used to use A and "1" (which was merge base between B and
      C).  That was pointless --- "merge-base A 1" is guaranteed to give a base
      that is no better than either "merge-base A B" or "merge-base A C".  So
      the current code keeps using the original head (iow, MRC=C, because in
      this case we are starting from C and merging B and then A into it).
      This trickerly was necessary only because we avoided creating the extra
      merge commit object M.
      	Side note.  An alternative implementation could have been to
      	actually record it as a real merge commit M, and then let the
      	two-commit merge-base compute the base between A and M when
      	merging A to the result of the previous round, but we avoided
      	creating M, at the expense of potentially using suboptimal base in
      	the later rounds.
      But we do not have to be that pessimistic.  We can instead accumulate the
      commits we have merged so far in MRC, and have merge_bases_many() compute
      the merge base for the new head being merged and the heads we have
      processed so far, which can give a better base than what we currently do.
      Signed-off-by: default avatarJunio C Hamano <>
  5. 03 Jul, 2007 1 commit
  6. 07 Feb, 2006 1 commit
    • Junio C Hamano's avatar
      read-tree --aggressive · 1b1fdf8c
      Junio C Hamano authored
      A new flag --aggressive resolves what we traditionally resolved
      with external git-merge-one-file inside index while read-tree
      3-way merge works.
      git-merge-octopus and git-merge-resolve use this flag before
      running git-merge-index with git-merge-one-file.
      Signed-off-by: default avatarJunio C Hamano <>
  7. 15 Jan, 2006 1 commit
  8. 13 Jan, 2006 1 commit
    • Junio C Hamano's avatar
      octopus: allow criss-cross and clarify the message when it rejects · c884dd9a
      Junio C Hamano authored
      We rejected multi-base merge situations even though we used the
      same underlying multi-base git-read-tree as the resolve strategy
      uses.  This was unneeded and did not add much to ensure the
      merge to be truly trivial, so remove this restriction and be
      more similar to what resolve does.
      Also when the merge did not trivially resolve, we rejected
      without stating that octopus strategy does not handle the
      Signed-off-by: default avatarJunio C Hamano <>
  9. 29 Nov, 2005 1 commit
  10. 11 Nov, 2005 1 commit
  11. 11 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Multi-backend merge driver. · 91063bbc
      Junio C Hamano authored
      The new command 'git merge' takes the current head and one or more
      remote heads, with the commit log message for the automated case.
      If the heads being merged are simple fast-forwards, it acts the
      same way as the current 'git resolve'.  Otherwise, it tries
      different merge strategies and takes the result from the one that
      succeeded auto-merging, if there is any.
      If no merge strategy succeeds auto-merging, their results are
      evaluated for number of paths needed for hand resolving, and the
      one with the least number of such paths is left in the working
      tree.  The user is asked to resolve them by hand and make a
      commit manually.
      The calling convention from the 'git merge' driver to merge
      strategy programs is very simple:
       - A strategy program is to be called 'git-merge-<strategy>'.
       - They take input of this form:
      	<common1> <common2> ... '--' <head> <remote1> <remote2>...
         That is, one or more the common ancestors, double dash, the
         current head, and one or more remote heads being merged into
         the current branch.
       - Before a strategy program is called, the working tree is
         matched to the current <head>.
       - The strategy program exits with status code 0 when it
         successfully auto-merges the given heads.  It should do
         update-cache for all the merged paths when it does so -- the
         index file will be used to record the merge result as a
         commit by the driver.
       - The strategy program exits with status code 1 when it leaves
         conflicts behind.  It should do update-cache for all the
         merged paths that it successfully auto-merged, and leave the
         cache entry in the index file as the same as <head> for paths
         it could not auto-merge, and leave its best-effort result
         with conflict markers in the working tree when it does so.
       - The strategy program exists with status code other than 0 or
         1 if it does not handle the given merge at all.
      As examples, this commit comes with merge strategies based on
      'git resolve' and 'git octopus'.
      Signed-off-by: default avatarJunio C Hamano <>