From: Philip Oakley <philipoakley@iee.email>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes.Schindelin@gmx.de, alexhenrie24@gmail.com,
git@vger.kernel.org, newren@gmail.com, phillip.wood123@gmail.com,
tao@klerks.biz
Subject: Re: [PATCH 1/1] doc: Glossary, describe Flattening
Date: Sat, 27 May 2023 17:28:57 +0100 [thread overview]
Message-ID: <43ff85b1-9f1d-480c-10fa-a856f625e35e@iee.email> (raw)
In-Reply-To: <xmqqh6seaxlk.fsf@gitster.g>
My somewhat delayed response..
On 15/05/2023 07:59, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> +[[def_flatten]]flatten::
>> + Flattening is a common term for the 'linearizing' of a
>> + selected portion of the <<def_commit_graph_general,commit graph>>.
>> + Flattening may include excluding commits, or rearranging commits,
>> + for the linearized sequence.
> Thanks for writing. I agree that it is a good idea to define the
> verb "flatten". The above I agree with 100%.
>
> I think I was one of the first ones who used the verb in the context
> of Git; what I wanted to convey with the verb was what it happens
> when you use "am" to rebuild some history made into a series of
> patches using the "format-patch" command on a part of the history.
That is useful context.
>
> When you have materials from two or more topic branches merged to
> your primary integration branch, you would omit the merge commits on
> the integration branch
I think that implicitly such patches can't include any (the
non-existent) 'merge-patches'..
> and send patches for commits on these topics
> in a linearized way. Applying these patches one by one will result
> in a linearlized history, containing patches from all of these
> topics (hopefully this is done in a topological order).
and hence chronological order as a secondary effect
>> + In particular, linkgit:git-log[1] and linkgit:git-show[1] have a
>> + range of "History Simplification" techniques that affect which
>> + commits are included, and how they are linearized.
> I didn't think (and I do not yet agree, but I may change my mind
> after thinking about it further) that the history simplification had
> much to do with flattening.
I was looking at the 'linearised' (i.e. an ordered list) viewpoint, as I
didn't have that historic context you mentioned.
>
> Even after a history is simplified (in the sense how rev-list family
> of commands do so), there will still be merge commits left if both
> branches contribute something to the end result. So unless a merge
> is to cauterize the side branch (i.e. in order to record the fact
> that we already have everything we may want possibly merge to the
> integration branch from the side branch, we create a merge commit
> that merges the branch but does not change the tree from the parent
> commit on the integration branch), history simplification may not
> contribute to "excluding" commits.
In the linear list perspective, the dropping of commits as
'simplification' would be "excluding" them, in exactly the same way that
the patch list had dropped merge commits..
>
>> + The default linkgit:git-rebase[1] will drop merge commits when it
>> + flattens history, which also may be unexpected.
> I am tempted to suggest dropping ", which also may be unexpected"
> here. When learning a new system, there may be things a learner may
> not expect (that is why we have documents),
Cautions and warnings, in my view, should be part of the manual,
especially if they keep coming back to bite folks. "Try it, fail and
lose work" isn't ideal when trying to learn unfamiliar techniques.
> so it is not all that
> useful to say "this may not be expected", expecially if we do not
> mention why it behaves that way to clear the "unexpected"-ness.
true.
>
> And in this case, the reason may be obvious and it is OK to be left
> unsaid---"git rebase" (without an option to keep merge commits) was
> designed to be a way to flatten history, and a flattened history by
> definition cannot have any merge commits in it.
as long as we don't conflate it with rev-list family linear listings..
>
>> + The two common linearization types are chronological (date-time), and
>> + topological (shape) based orderings. Generation numbering is topological.
> Good.
Thanks.
--
Philip
next prev parent reply other threads:[~2023-05-27 16:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-20 3:32 [PATCH 1/2] rebase: add a --rebase-merges=drop option Alex Henrie
2023-02-20 3:32 ` [PATCH 2/2] rebase: add a config option for --rebase-merges Alex Henrie
2023-02-20 9:38 ` Phillip Wood
2023-02-20 17:06 ` Alex Henrie
2023-02-20 16:41 ` Elijah Newren
2023-02-20 9:31 ` [PATCH 1/2] rebase: add a --rebase-merges=drop option Phillip Wood
2023-02-20 17:03 ` Alex Henrie
2023-02-20 21:42 ` Junio C Hamano
2023-02-21 16:08 ` Philip Oakley
2023-02-21 18:42 ` Junio C Hamano
2023-05-13 16:51 ` [PATCH 0/1] cover-letter: flatten Philip Oakley
2023-05-13 16:56 ` [PATCH 1/1] doc: Glossary, describe Flattening Philip Oakley
2023-05-15 6:59 ` Junio C Hamano
2023-05-27 16:28 ` Philip Oakley [this message]
2023-05-19 21:35 ` Kristoffer Haugsbakk
2023-05-27 16:46 ` Philip Oakley
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43ff85b1-9f1d-480c-10fa-a856f625e35e@iee.email \
--to=philipoakley@iee.email \
--cc=Johannes.Schindelin@gmx.de \
--cc=alexhenrie24@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=tao@klerks.biz \
/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.
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).