Multi-backend merge driver.
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: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Junio C Hamano
|
|
|
|
#
|
|
|
|
# Resolve two or more trees.
|
|
|
|
#
|
|
|
|
|
2005-11-10 07:37:14 +01:00
|
|
|
LF='
|
|
|
|
'
|
|
|
|
|
Multi-backend merge driver.
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: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
|
|
|
# The first parameters up to -- are merge bases; the rest are heads.
|
|
|
|
bases= head= remotes= sep_seen=
|
|
|
|
for arg
|
|
|
|
do
|
|
|
|
case ",$sep_seen,$head,$arg," in
|
|
|
|
*,--,)
|
|
|
|
sep_seen=yes
|
|
|
|
;;
|
|
|
|
,yes,,*)
|
|
|
|
head=$arg
|
|
|
|
;;
|
|
|
|
,yes,*)
|
|
|
|
remotes="$remotes$arg "
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
bases="$bases$arg "
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
|
|
|
# Reject if this is not an Octopus -- resolve should be used instead.
|
|
|
|
case "$remotes" in
|
|
|
|
?*' '?*)
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
exit 2 ;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
# MRC is the current "merge reference commit"
|
|
|
|
# MRT is the current "merge result tree"
|
|
|
|
|
|
|
|
MRC=$head MSG= PARENT="-p $head"
|
|
|
|
MRT=$(git-write-tree)
|
|
|
|
CNT=1 ;# counting our head
|
|
|
|
NON_FF_MERGE=0
|
|
|
|
for SHA1 in $remotes
|
|
|
|
do
|
2005-11-10 07:37:14 +01:00
|
|
|
common=$(git-merge-base --all $MRC $SHA1) ||
|
Multi-backend merge driver.
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: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
|
|
|
die "Unable to find common commit with $SHA1"
|
|
|
|
|
2005-11-10 07:37:14 +01:00
|
|
|
case "$common" in
|
|
|
|
?*"$LF"?*)
|
|
|
|
die "Not trivially mergeable."
|
|
|
|
;;
|
|
|
|
$SHA1)
|
Multi-backend merge driver.
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: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
|
|
|
echo "Already up-to-date with $SHA1"
|
|
|
|
continue
|
2005-11-10 07:37:14 +01:00
|
|
|
;;
|
|
|
|
esac
|
Multi-backend merge driver.
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: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
|
|
|
|
|
|
|
CNT=`expr $CNT + 1`
|
|
|
|
PARENT="$PARENT -p $SHA1"
|
|
|
|
|
|
|
|
if test "$common,$NON_FF_MERGE" = "$MRC,0"
|
|
|
|
then
|
|
|
|
# The first head being merged was a fast-forward.
|
|
|
|
# Advance MRC to the head being merged, and use that
|
|
|
|
# tree as the intermediate result of the merge.
|
|
|
|
# We still need to count this as part of the parent set.
|
|
|
|
|
|
|
|
echo "Fast forwarding to: $SHA1"
|
|
|
|
git-read-tree -u -m $head $SHA1 || exit
|
|
|
|
MRC=$SHA1 MRT=$(git-write-tree)
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
|
|
|
NON_FF_MERGE=1
|
|
|
|
|
|
|
|
echo "Trying simple merge with $SHA1"
|
|
|
|
git-read-tree -u -m $common $MRT $SHA1 || exit 2
|
|
|
|
next=$(git-write-tree 2>/dev/null)
|
|
|
|
if test $? -ne 0
|
|
|
|
then
|
|
|
|
echo "Simple merge did not work, trying automatic merge."
|
|
|
|
git-merge-index -o git-merge-one-file -a ||
|
|
|
|
exit 2 ; # Automatic merge failed; should not be doing Octopus
|
|
|
|
next=$(git-write-tree 2>/dev/null)
|
|
|
|
fi
|
2005-11-10 07:37:14 +01:00
|
|
|
|
|
|
|
# We have merged the other branch successfully. Ideally
|
|
|
|
# we could implement OR'ed heads in merge-base, and keep
|
|
|
|
# a list of commits we have merged so far in MRC to feed
|
|
|
|
# them to merge-base, but we approximate it by keep using
|
|
|
|
# the current MRC. We used to update it to $common, which
|
|
|
|
# was incorrectly doing AND'ed merge-base here, which was
|
|
|
|
# unneeded.
|
|
|
|
|
Multi-backend merge driver.
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: Junio C Hamano <junkio@cox.net>
2005-09-08 22:47:12 +02:00
|
|
|
MRT=$next
|
|
|
|
done
|
|
|
|
|
|
|
|
exit 0
|