Clarify the term 'flatten' and the unexpected effects that the user may come across, such as discussed in [1] and [2]. [1] https://lore.kernel.org/git/xmqqr0ukggk5.fsf@gitster.g/ [2] https://lore.kernel.org/git/xmqq5ybug8s8.fsf@gitster.g/ Signed-off-by: Philip Oakley <philipoakley@iee.email> --- Documentation/glossary-content.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 5a537268e2..36125e503c 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -173,6 +173,19 @@ current branch integrates with) obviously do not work, as there is no missing from the local <<def_object_database,object database>>, and to get them, too. See also linkgit:git-fetch[1]. +[[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. + 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. + The default linkgit:git-rebase[1] will drop merge commits when it + flattens history, which also may be unexpected. + The two common linearization types are chronological (date-time), and + topological (shape) based orderings. Generation numbering is topological. + [[def_file_system]]file system:: Linus Torvalds originally designed Git to be a user space file system, i.e. the infrastructure to hold files and directories. That ensured the -- 2.40.0.windows.1
