kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Stephen Boyd	f08aa01767	octopus: remove dead code MSG, PARENT, and CNT are never used, just assigned to. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephen Boyd	85bf49f9a5	octopus: reenable fast-forward merges The fast-forward logic is never being triggered because $common and $MRC are never equivalent. $common is initialized to a commit id by merge-base and MRC is initialized to HEAD. Fix this by initializing $MRC to the commit id for HEAD so that its possible for $MRC and $common to be equal. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephen Boyd	81334502ee	octopus: make merge process simpler to follow Its not very easy to understand what heads are being merged given the current output of an octopus merge. Fix this by replacing the sha1 with the (usually) better description in GITHEAD_<SHA1>. Suggested-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Felipe Contreras	a75d7b5409	Use 'fast-forward' all over the place It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	c5dc9a2829	git-merge-octopus: use (merge-base A (merge B C D E...)) for stepwise merge 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---o---C / : / o---o---o---B..(M) / / ---1---2---o---o---o---A 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 base. 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: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	5be60078c9	Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	1b1fdf8c2f	read-tree --aggressive 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>	19 years ago
Junio C Hamano	98efc8f3d8	octopus: allow manual resolve on the last round. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	c884dd9a54	octopus: allow criss-cross and clarify the message when it rejects 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>	19 years ago
Junio C Hamano	d165fa14f0	define die() for scripts that use it. 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>	19 years ago
Junio C Hamano	17cf939724	octopus: do not do AND'ed merge base. 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>	19 years ago
Junio C Hamano	91063bbc6c	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>	20 years ago

11 Commits (85e2233f982f760d0e731b1258da2580834d8027)