Martin Langhoff wants to use git-merge from outside git-pull and wants
to do further processing; for this, he wants git-merge no to commit
even when it cleanly merges. I think other script writers would want
something like that as well, so here it is.
Instead of the "merge commit message" parameter (which usually is made
for you by "git-pull" which calls this command), you pass an empty
string to it. Then it will not update your HEAD -- you can do whatever
you want with the resulting index file, which contains the merge results.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let the merge strategies handle the base less case if they are able to
do it. It also fixes git-resolve.sh to die if no common ancestors
exists, instead of doing the wrong thing. Furthermore, it contains a
small independent fix for git-merge.sh and a fix for a base less code
path in gitMergeCommon.py.
With this it's possible to use
git merge -s recursive 'merge message' A B
to do a base less merge of A and B.
[jc: Thanks Fredrik for fixing the brown-paper-bag in git-merge.
I fixed a small typo in git-merge-resolve fix; 'test' equality
check is spelled with single equal sign -- C-style double equal
sign is bashism.]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using Linus' --trivial option, this handles really trivial case
inside git-merge itself, without using any strategy modules.
A 'really trivial case' is:
- we are merging one branch into the current branch;
- there is only one merge base between the branches;
- there is no file-level merge required.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse. This will matter when we start using symbolic
references.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The merge strategy would check this itself and typically does it
by using git-read-tree -m -u 3-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Being able to try multiple strategies and automatically picking one
that seems to give less conflicting result may or may not much sense
in practice. At least that should not force normal use case to
additionally require the working tree to be fully clean. As Linus
shouted, local changes do not matter unless they interfere with the
merge.
This commit changes git-merge not to require a clean working tree.
Only when we will iterate through more than one merge strategies,
local changes are stashed away before trying the first merge, and
restored before second and later merges are attempted.
The index file must be in sync with HEAD in any case -- otherwise the
merge result would contain changes since HEAD that was done locally
and registered in the index. This check is already enforced by
three-way read-tree existing merge strategies use, but is done here as
a safeguard as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The merge strategies can give more descriptive error messages for
conflict cases if they are given the actual branch names instead of
the SHA1s.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise we would regret when Fredrik comes up with another merge
algorithm with different pros-and-cons with the current one.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I really wanted to try this out, instead of asking for an adjustment
to the 'git merge' driver and waiting. For now the new strategy is
called 'fredrik' and not in the list of default strategies to be tried.
The script wants Python 2.4 so this commit also adjusts Debian and RPM
build procecure files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
