From: Junio C Hamano <gitster@pobox.com>
To: "William Sprent via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, William Sprent <williams@unity3d.com>
Subject: Re: [PATCH] fast-export: fix surprising behavior with --first-parent
Date: Tue, 23 Nov 2021 16:41:00 -0800 [thread overview]
Message-ID: <xmqqh7c25qsj.fsf@gitster.g> (raw)
In-Reply-To: <pull.1084.git.1637666927224.gitgitgadget@gmail.com> (William Sprent via GitGitGadget's message of "Tue, 23 Nov 2021 11:28:47 +0000")
"William Sprent via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 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.
next prev parent reply other threads:[~2021-11-24 0:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 11:28 [PATCH] fast-export: fix surprising behavior with --first-parent William Sprent via GitGitGadget
2021-11-23 13:07 ` Ævar Arnfjörð Bjarmason
2021-11-24 11:57 ` William Sprent
2021-11-23 19:14 ` Elijah Newren
2021-11-24 13:05 ` William Sprent
2021-11-24 0:41 ` Junio C Hamano [this message]
2021-11-24 13:05 ` William Sprent
2021-12-09 8:13 ` [PATCH v2] " William Sprent via GitGitGadget
2021-12-10 3:48 ` Elijah Newren
2021-12-10 21:55 ` Junio C Hamano
2021-12-10 22:02 ` Elijah Newren
2021-12-13 15:09 ` William Sprent
2021-12-14 0:31 ` Elijah Newren
2021-12-14 13:11 ` William Sprent
2021-12-16 16:23 ` [PATCH v3] " William Sprent via GitGitGadget
2021-12-21 18:47 ` Elijah Newren
2021-12-21 20:50 ` Junio C Hamano
2021-12-22 8:38 ` William Sprent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh7c25qsj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=williams@unity3d.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).