aboutsummaryrefslogtreecommitdiff
path: root/git-merge-octopus.sh
Commit message (Collapse)AuthorAge
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-02
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* read-tree --aggressiveJunio C Hamano2006-02-06
| | | | | | | | | | | 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: Junio C Hamano <junkio@cox.net>
* octopus: allow manual resolve on the last round.Junio C Hamano2006-01-14
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* octopus: allow criss-cross and clarify the message when it rejectsJunio C Hamano2006-01-13
| | | | | | | | | | | | | | 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 situation. Signed-off-by: Junio C Hamano <junkio@cox.net>
* define die() for scripts that use it.Junio C Hamano2005-11-28
| | | | | | | | | As a fallout from not using git-sh-setup in scripts that can operate from a subdirectory, we lost definition of die() from them. It might make sense to do some cleanup to consolidate them back again, but this should suffice for now. Signed-off-by: Junio C Hamano <junkio@cox.net>
* octopus: do not do AND'ed merge base.Junio C Hamano2005-11-11
| | | | | | | | | When doing an octopus, we incorrectly used the previous merge base as the reference to compute next merge base. This was unnecessary, because that can never be better than using the original HEAD. And that is far simpler as well ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
* Multi-backend merge driver.Junio C Hamano2005-09-10
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>