Re: [PATCH] fast-export: fix surprising behavior with --first-parent

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 24, 2021, 00:41 UTC
Message-ID: <xmqqh7c25qsj.fsf@gitster.g>
In-Reply-To: <pull.1084.git.1637666927224.gitgitgadget@gmail.com>

"William Sprent via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 6 quoted lines

> From: William Sprent <williams@unity3d.com>
>
> When invoking git-fast-export with the --first-parent flag on a branch
> with merges, fast-export would early-out on processing the first merge
> on the branch. If combined with --reverse, fast-export would instead
> output all single parent commits on the branch.

I do not doubt we would want to make the command behave sensibly with all options it accepts, but let me first ask a more basic and possibly stupid question.

What is "git fast-export --first-parent <options>" supposed to do differently from "git fast-export <options>" (with the same set of options other than "--first-parent")? Should it omit merge commits altogether, pretending that the first single-parent ancestor it finds on the first parent chain is a direct parent of a single-parent descendant, e.g. if the real history were with two single-parente commits A and B, with two merges M and N, on the mainline, making the resulting commits into a single strand of two pearls, with A and B before and after the rewrite to have the same tree objects?

    ---A---M---N---B             ---A---B
          /   /           ==>
         X   Y

Or should it pretend merge commits have only their first parent as their parents, i.e.

    ---A---M---N---B             ---A---M---N---B
          /   /           ==>
         X   Y

"git fast-export --help" does not even mention "--first-parent" and pretend that any and all [<git-rev-list-args>...] are valid requests to make to the command, but I am wondering if that is what we intend to support in the first place. In builtin/fast-export.c, I do not see any attempt to do anything differently when "--first-parent" is requested. Perhaps we shouldn't be even taking "--first-parent" as an option to begin with.

The "--reverse" feels even more iffy. Are we reversing the history with such an export, i.e. pretending that parents are children and merges are forks?

    ---A---M---N---B             B---N---M---A---
          /   /           ==>         \   \
         X   Y                         X   Y

Or are we supposed to produce the same history in the end, just spewing older commits first in the output stream? I am not sure what purpose such a request serves---the "fast-import" downstream would need the same set of objects before it can create each commit anyway, so I am not sure what the point of giving "--reverse" is.

If there is no sensible interpretation for some of the options that are valid in rev-list in the context of "fast-export" command, should we just error out when we parse the command line, instead of producing nonsense output stream, I wonder.