0

All of you comfortable with example and elaborations in git log's help for history simplification? I encounter some burdens on understanding when using this help/manual and the named example. 

  .-A---M---N---O---P---Q
 /     /   /   /   /   /
I     B   C   D   E   Y
 \   /   /   /   /   /
  `-------------'   X
  • I is the initial commit... foo exists with contents “asdf”, and a file quux exists with contents “quux”....
  • In A, foo contains just “foo”...
  • B contains the same change as A...
  • C does not change foo, but its merge N changes it to “foobar”...
  • P is TREESAME to O...
  • The sense of a merge with a change not present in any of its parents included? See merge's N description in git log's help
  • The file's quux undergoes some modifications on the transition from O to merge P, why do the elaborations in help qualify P as treesame against O?

It looks like the terms TREESAME and !TREESAME are to be seen in scope of a single file/directory. Not to be used to express commit property for multiple files. Is this true?

1 Answers1

1

The TREESAME expressions in the description are applied to the trees of each commit (pairwise as they are being compared) after doing any file-specific filtering from your git log command. For instance:

git log --simplify-merges

compares every file in each tree to decide whether two commit trees are "the same", while:

git log --simplify-merges -- README

compares only the README file in each tree, and:

git log --simplify-merges -- README dir1 dir2

leaves README and any files within the two directories in the tree before comparing the trees.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Mentioned example and elaborations in git log's help does not make any constrains regarding files filtering. It tells about just two files, so me assumes no filtering is to be considered in these elaborations. My question is still open. –  Feb 02 '16 at 09:12
  • I know that the documentation fails to say this, but that's what actually happens: git effectively discards any parts of the tree you designate as irrelevant (by listing parts that you consider relevant) before doing the TREESAME compare. If you do not list any parts, git compares the unmodified trees, i.e., everything is relevant. – torek Feb 02 '16 at 09:43
  • This answer along with attached comment from torek answers my question. Thank you. –  Feb 03 '16 at 16:31