{"thread":{"id":"14380","subject":"Merging \"merge-in-c\" to next.","startedAt":"2008-07-09T21:20:10Z","lastAt":"2008-07-09T21:20:10Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"82752","messageId":"7vej627o1h.fsf@gitster.siamese.dyndns.org","threadId":"14380","inReplyTo":null,"subject":"Merging \"merge-in-c\" to next.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-09T21:20:10Z","receivedAt":"2008-07-09T21:20:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I am preparing to merge the 'merge-in-c' topic from Miklos to 'next'. The\ntopic introduces builtin-merge.c to rewrite git-merge.sh script in C.\n\nOne interesting aspect of this merge is that 'next' has an enhanced\ngit-merge that can pass extra options that git-merge itself does not have\nto understand to the strategy backends, when the user gives -X to\nit. This is analogous to how gcc uses -Wl,* option to pass options to the\nlinker. This new feature comes from a separate merge-theirs topic\ndeveloped independently. Naturally, merge-in-c does not know about it.\n\nThe approach I am taking with this integration is to first fork a new\nbranch (a mini-integration branch) 'xx/merge-in-c-into-next' from\n'mv/merge-in-c', and then:\n\n - Merge 'ph/parseopt-step-blame' topic to it;\n\n - Convert the use of parse_options() in 'git-merge' to use \"incremental\n parsing\" that is introduced by the 'ph/parseopt-step-blame' topic;\n\n - Merge 'jc/merge-theirs' topic, marking \"git merge -Xtheirs\" feature is\n temporarily broken in the test suite;\n\n - Add support for -X ;\n\n - And finally merge the whole thing to 'next'.\n\nThe idea is that:\n\n * This would hopefully not break 'next', obviously;\n\n * If either one of merge-theirs or merge-in-c (but not both) matures\n early and needs to graduate to master, it can do so; this fact is\n indepent from today's merge;\n\n * After one of these interacting topics graduates to 'master', merging\n the other one to 'master' will need to resolve the same semantic\n conflict as I am resolving today. Merging this mini-integration topic\n to 'master' instead of mergint the other one would be straightforward\n and much less error prone.\n\nThis approach takes the aggregation hostage to ph/parseopt-step-blame; in\norder to merge both merge-in-c and merge-theirs to master, we must merge\nthe incremental option parser to master as well. But I think that is not\na problem -- the parseopt change in question is something we would want to\nhave in 'master' fairly soon.\n\nThe commit log messages for merge commits in this series are actually\ninteresting. Output of \"git log --reverse --stat --first-parent\" is\nattached at the end.\n\n\ncommit 1c7b76be7d620bbaf2e6b8417f04012326bbb9df\nAuthor: Miklos Vajna \nDate: Mon Jul 7 19:24:20 2008 +0200\n\n Build in merge\n \n Mentored-by: Johannes Schindelin \n Signed-off-by: Miklos Vajna \n Signed-off-by: Junio C Hamano \n\n Makefile | 2 +-\n builtin-merge.c | 1153 +++++++++++++++++++++++++++++++++++++++++\n builtin.h | 1 +\n contrib/examples/git-merge.sh | 554 ++++++++++++++++++++\n git-merge.sh | 554 --------------------\n git.c | 1 +\n t/t7602-merge-octopus-many.sh | 2 +-\n 7 files changed, 1711 insertions(+), 556 deletions(-)\n\ncommit ff0d8a01410d1d2363dec660fc87b99905691d57\nMerge: 1c7b76b... 3f8d520...\nAuthor: Junio C Hamano \nDate: Wed Jul 9 11:11:48 2008 -0700\n\n Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next\n \n The purpose of this branch is to resolve interactions with the merge-in-c\n and the merge-theirs topics before merging the former into 'next'. Use of\n parse_options_step() would be a good way to support -X where\n git-merge needs to passes it through to the strategy modules without\n having to understand what is.\n \n This will be needed when merge-in-c is merged to 'next', which already has\n the merge-theirs topic. We do not merge this mini-integration branch to\n 'master' if we later decide to drop merge-theirs, or merge merge-in-c\n first to 'master', If we are to merge both to 'master', then merging this\n branch would suffice.\n\ncommit ffa6e85e1cfca7ce3f41f5bfd420b94a26aa57bf\nAuthor: Junio C Hamano \nDate: Wed Jul 9 12:58:22 2008 -0700\n\n builtin-merge.c: use parse_options_step() \"incremental parsing\" machinery\n \n This prepares the option parser for \"git-merge\" to use the incremental\n parsing machinery, so that we can add support for -X passthru\n that is hard to parse with the stop parse_options() machinery.\n \n This is just a conversion; it does not add any new options nor features\n yet.\n \n Signed-off-by: Junio C Hamano \n\n builtin-merge.c | 45 ++++++++++++++++++++++++++++++++++++++++-----\n 1 files changed, 40 insertions(+), 5 deletions(-)\n\ncommit fd6fd913327812ecce7d638846b88908b350b904\nMerge: ffa6e85... 7eda236...\nAuthor: Junio C Hamano \nDate: Wed Jul 9 13:00:24 2008 -0700\n\n Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next\n \n This is an evil merge that tentatively marks that the \"git merge -Xtheirs\"\n is broken in the testsuite, because \"git merge\" reimplementation in C does\n not know about it yet.\n \n * jc/merge-theirs:\n Make \"subtree\" part more orthogonal to the rest of merge-recursive.\n Teach git-pull to pass -X to git-merge\n Teach git-merge to pass -X to the backend strategy module\n git-merge-recursive-{ours,theirs}\n git-merge-file --ours, --theirs\n\ncommit aa85524eacdfa9fa84727dd700265f3a70b8fd01\nAuthor: Junio C Hamano \nDate: Wed Jul 9 13:51:46 2008 -0700\n\n Teach git-merge -X again.\n \n This fixes the tentative regression of git-merge rewritten in C by\n teaching it to pass -X to the strategy backends.\n \n Signed-off-by: Junio C Hamano \n\n builtin-merge.c | 55 ++++++++++++++++++++++++++++++-----------\n t/t6034-merge-ours-theirs.sh | 4 +-\n 2 files changed, 42 insertions(+), 17 deletions(-)\n"}]}