Re: [PATCH] builtin-commit: avoid using reduce_heads()

[Jakub Narebski <jnareb@gmail.com>]

Miklos Vajna <vmiklos@frugalware.org> writes:

> OK, here is the scenario.
> 
> The basic problemis that if it's git-commit that creates the merge
> commit and not git-merge, then git-commit does not "know" that git-merge
> was invoked using --no-ff.
> 
> --no-ff means that if reduce_heads() removes a parent, that will be a
> problem, since the resulting commit will no longer be a merge commit.
> 
> I think we can't avoid storing this info in a MERGE_MODE file, because
> we have to add HEAD to the list of parents in case --no-ff is used, but
> we should not do so in case it's reachable from existing heads and
> --no-ff is not used.
> 
> I'll send a patch that does this in a bit.

The following is summary of short dicussion about this issue on #git
see: http://colabti.org/irclogger/irclogger_log/git?date=2008-09-26,Fri#l1176

The problem is that sometimes git-commit finishes doing the merge, be
it use of --no-commit option, or a conflict occurred; depending on
whether git-merge was invoked with or without --no-ff (--ff=never)
option it should recurd reduced or non-reduced heads.

The problem for example occurs in the following situation:

  .---.---.---.                  <--- a <--- HEAD
              |\
              | \-1---2          <--- b
              \
               \--x---y          <--- c

$ git merge b c

                      /------------- b 
                      v
  .---.---.---.---1---2---M     <--- a <--- HEAD
              \          /
               \--x---y-/       <--- c

$ git merge --no-ff b c

  .---.---.---.---------M         <--- a <--- HEAD
              |\       /|
              | \-1---2 |         <--- b
              \         /
               \--x---y/          <--- c



We can select one of the following solutions:

1. As proposed above save git-merge options, for example in MERGE_MODE
   or MERGE_OPTS file, so git-commit knows what options to use if it
   was invoked to finish a merge.

2. git-merge saves _reduced_ heads in MERGE_HEAD, and git-commit
   reduces only HEAD, unless it is in MERGE_HEAD.  This means that
   git-commit uses the following pseudo-code

     if (resolve_ref(HEAD) == MERGE_HEAD[0]) {
        /* non fast-forward case */
        merge HEAD + MERGE_HEAD
     } else {
        reduce_HEAD_maybe()
        merge [HEAD] + MERGE_HEAD
     }

   This has the advantage that it doesn't change MERGE_HEAD semantic
   for simple merge which did not began as octopus

3. Remove reduce_heads() from git-commit entirely, and record in
   MERGE_HEAD (or rather now MERGE_HEADS) _all_ _reduced_ heads.
   _All_ means that HEAD is included in MERGE_HEAD if it is not
   reduced, _reduced_ means that only non-dependent heads are in
   MERGE_HEAD.  This for example means that for simple non-octopus
   merge case MERGE_HEAD/MERGE_HEADS now contain _all_ parents,
   and not only other side of merge.

   This solution has the advantage of being clear solution, clarifying
   semantic of MERGE_HEAD (currently HEAD is used both as target, i.e.
   where merge is to be recorded, and as one of heads to merge/to
   consider), and making it possible to separate layers: git-merge
   is about merging, git-commit doesn't need to know anything about
   merging.

   The disadvantage is that it changes format (well, semantic) of
   MERGE_HEAD, possibly breaking users' scripts; perhaps some of
   git commands like "git log --merge" or "git diff --merge" should
   be updated on such change.

-- 
Jakub Narebski
Poland
ShadeHawk on #git