Johannes Sixt wrote:
> - The 'git merge' invocation passed the commit message of the old merge
> commit, but it still obeyed the merge.log option. If it was set, the log
> ended up twice in the commit message.
Likewise for the "Conflicts:" paragraph, which should also be pretty
simple to fix directly. I don't think that points directly to a
fundamental flaw in the current implementation, but it does make it
seem like no one has been using "rebase -p" for anything nontrivial. :)
[...]
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -312,12 +312,14 @@ pick_one_preserving_merges () {
> msg_content="$(commit_message $sha1)"
> # No point in merging the first parent, that's HEAD
> new_parents=${new_parents# $first_parent}
> - if ! do_with_author output \
> - git merge --no-ff ${strategy:+-s $strategy} -m \
> - "$msg_content" $new_parents
> + printf "%s\n" $new_parents >"$GIT_DIR"/MERGE_HEAD
> + printf "%s\n" "$msg_content" >"$GIT_DIR"/MERGE_MSG
> + if output git cherry-pick -m 1 -n "$sha1"
> then
> + do_with_author output git commit --no-verify -F "$GIT_DIR"/MERGE_MSG ||
> + die_with_patch $sha1 "Could not replay merge $sha1"
> + else
> - printf "%s\n" "$msg_content" > "$GIT_DIR"/MERGE_MSG
> - die_with_patch $sha1 "Error redoing merge $sha1"
> + die_with_patch $sha1 "Could not pick merge $sha1"
> fi
Cute. The approach looks very sensible to me.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html