From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 09 Jul 2008 21:20:10 GMT
Subject: Merging "merge-in-c" to next.
Message-ID: <7vej627o1h.fsf@gitster.siamese.dyndns.org>

I am preparing to merge the 'merge-in-c' topic from Miklos to 'next'.  The
topic introduces builtin-merge.c to rewrite git-merge.sh script in C.

One interesting aspect of this merge is that 'next' has an enhanced
git-merge that can pass extra options that git-merge itself does not have
to understand to the strategy backends, when the user gives -X<option> to
it.  This is analogous to how gcc uses -Wl,* option to pass options to the
linker.  This new feature comes from a separate merge-theirs topic
developed independently.  Naturally, merge-in-c does not know about it.

The approach I am taking with this integration is to first fork a new
branch (a mini-integration branch) 'xx/merge-in-c-into-next' from
'mv/merge-in-c', and then:

 - Merge 'ph/parseopt-step-blame' topic to it;

 - Convert the use of parse_options() in 'git-merge' to use "incremental
   parsing" that is introduced by the 'ph/parseopt-step-blame' topic;

 - Merge 'jc/merge-theirs' topic, marking "git merge -Xtheirs" feature is
   temporarily broken in the test suite;

 - Add support for -X<option>;

 - And finally merge the whole thing to 'next'.

The idea is that:

 * This would hopefully not break 'next', obviously;

 * If either one of merge-theirs or merge-in-c (but not both) matures
   early and needs to graduate to master, it can do so; this fact is
   indepent from today's merge;

 * After one of these interacting topics graduates to 'master', merging
   the other one to 'master' will need to resolve the same semantic
   conflict as I am resolving today.  Merging this mini-integration topic
   to 'master' instead of mergint the other one would be straightforward
   and much less error prone.

This approach takes the aggregation hostage to ph/parseopt-step-blame; in
order to merge both merge-in-c and merge-theirs to master, we must merge
the incremental option parser to master as well.  But I think that is not
a problem -- the parseopt change in question is something we would want to
have in 'master' fairly soon.

The commit log messages for merge commits in this series are actually
interesting.  Output of "git log --reverse --stat --first-parent" is
attached at the end.


commit 1c7b76be7d620bbaf2e6b8417f04012326bbb9df
Author: Miklos Vajna <vmiklos@frugalware.org>
Date:   Mon Jul 7 19:24:20 2008 +0200

    Build in merge
    
    Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
    Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

 Makefile                      |    2 +-
 builtin-merge.c               | 1153 +++++++++++++++++++++++++++++++++++++++++
 builtin.h                     |    1 +
 contrib/examples/git-merge.sh |  554 ++++++++++++++++++++
 git-merge.sh                  |  554 --------------------
 git.c                         |    1 +
 t/t7602-merge-octopus-many.sh |    2 +-
 7 files changed, 1711 insertions(+), 556 deletions(-)

commit ff0d8a01410d1d2363dec660fc87b99905691d57
Merge: 1c7b76b... 3f8d520...
Author: Junio C Hamano <gitster@pobox.com>
Date:   Wed Jul 9 11:11:48 2008 -0700

    Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
    
    The purpose of this branch is to resolve interactions with the merge-in-c
    and the merge-theirs topics before merging the former into 'next'.  Use of
    parse_options_step() would be a good way to support -X<option> where
    git-merge needs to passes it through to the strategy modules without
    having to understand what <option> is.
    
    This will be needed when merge-in-c is merged to 'next', which already has
    the merge-theirs topic.  We do not merge this mini-integration branch to
    'master' if we later decide to drop merge-theirs, or merge merge-in-c
    first to 'master',  If we are to merge both to 'master', then merging this
    branch would suffice.

commit ffa6e85e1cfca7ce3f41f5bfd420b94a26aa57bf
Author: Junio C Hamano <gitster@pobox.com>
Date:   Wed Jul 9 12:58:22 2008 -0700

    builtin-merge.c: use parse_options_step() "incremental parsing" machinery
    
    This prepares the option parser for "git-merge" to use the incremental
    parsing machinery, so that we can add support for -X<options> passthru
    that is hard to parse with the stop parse_options() machinery.
    
    This is just a conversion; it does not add any new options nor features
    yet.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

 builtin-merge.c |   45 ++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 40 insertions(+), 5 deletions(-)

commit fd6fd913327812ecce7d638846b88908b350b904
Merge: ffa6e85... 7eda236...
Author: Junio C Hamano <gitster@pobox.com>
Date:   Wed Jul 9 13:00:24 2008 -0700

    Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
    
    This is an evil merge that tentatively marks that the "git merge -Xtheirs"
    is broken in the testsuite, because "git merge" reimplementation in C does
    not know about it yet.
    
    * jc/merge-theirs:
      Make "subtree" part more orthogonal to the rest of merge-recursive.
      Teach git-pull to pass -X<option> to git-merge
      Teach git-merge to pass -X<option> to the backend strategy module
      git-merge-recursive-{ours,theirs}
      git-merge-file --ours, --theirs

commit aa85524eacdfa9fa84727dd700265f3a70b8fd01
Author: Junio C Hamano <gitster@pobox.com>
Date:   Wed Jul 9 13:51:46 2008 -0700

    Teach git-merge -X<option> again.
    
    This fixes the tentative regression of git-merge rewritten in C by
    teaching it to pass -X<option> to the strategy backends.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

 builtin-merge.c              |   55 ++++++++++++++++++++++++++++++-----------
 t/t6034-merge-ours-theirs.sh |    4 +-
 2 files changed, 42 insertions(+), 17 deletions(-)