Junio C Hamano [off-list ref] writes:
Jonathan Nieder [off-list ref] writes:
quoted
Just to make sure I understand, here is what I think --cc does:
- In a two-parent merge, it is exactly as Linus has been
...
- In a many-parent merge, the criterion is more stringent.
...
Is that correct?
The logic in the code does not have separate criteria for two-parent and
Octopus cases. Actually Linus talks about "when you have two versions to
choose from, and if the result matches one of them, then it is not
interesting". In a two-parent merge, you cannot have three or more
possible versions to choose from by definition, can you?
To put it another way, I think what you wrote is correct, but two-parent
case is just a degenerated case of a more general rule, that is:
A hunk is not interesting if the person who merged had only two
choices offered by the parents to pick from, and the merge result
exactly matched one of the choices.
You can come up with examples that do not match the above criteria; they
are all interesting.
For example, if all the parent of a tripus disagreed, the person had more
than two choices to pick from, so no matter what the resolution is, the
hunk is interesting.
On the other hand, if 4 parents in a dodecapus lack a line that all other
8 parents have (see the first example in [*1*]), then the choice for the
person who merges these 12 parents is either to include or not include
that line. If the line was included, it is not interesting. If the line
was deleted (which is different from what happened in *1*), it is not
interesting, either.
One thing to note is "have only two choices to pick from" does not have a
direct connection to two-parent-ness. In a two-parent merge (di-pus?), by
definition you cannot have more than two choices, but that is not any
different from a Dodecapus that has only two groups of parents. Most
octopus merges have only two groups of parents like the "merge from hell"
does when we talk about individual paths (otherwise it would be very
painful to resolve so it is not done in practice).
[Reference]
*1* http://article.gmane.org/gmane.comp.version-control.git/15487
Junio C Hamano wrote:
Actually Linus talks about "when you have two versions to
choose from, and if the result matches one of them, then it is not
interesting".
That is much better - thanks. (The description by Linus I was referring
to was from
<http://thread.gmane.org/gmane.comp.version-control.git/89415>:
"So "--cc" only shows output if: the merge itself actually changed
something from _all_ parents" - which is not too misleading since the
two-parent case is the usual one.)
How about this, then?
Subject: document diff --cc's long-ago-changed semantics
In February 2006 [1], the definition of "interesting hunk" for
git's "compact combined diff" format changed, without any
corresponding change in documentation. This patch brings the
documentation up to date.
[1] commit bf1c32bdec8223785c779779d0a660a099f69a63
combine-diff: update --cc "uninteresting hunks" logic
---
Documentation/git-diff-tree.txt | 12 +++++++-----
Documentation/rev-list-options.txt | 9 +++++----
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 0e45b58..14dc70d 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -92,12 +92,14 @@ include::pretty-options.txt[]
--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
- and '-p' options and further compresses the patch output
- by omitting hunks that show differences from only one
- parent, or show the same change from all but one parent
- for an Octopus merge. When this optimization makes all
+ and '-p' options and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered uninteresting if the person merging had two versions
+ to choose between among all of the parents and the result shows
+ no changes from one of those versions.
+ When this optimization makes all
hunks disappear, the commit itself and the commit log
- message is not shown, just like in any other "empty diff" case.
+ message are not shown, just like in any other "empty diff" case.
--always::
Show the commit itself and the commit log message even
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b6f5d87..c61d05d 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -111,10 +111,11 @@ options may be given. See linkgit:git-diff-files[1] for more options.
--cc::
- This flag implies the '-c' options and further compresses the
- patch output by omitting hunks that show differences from only
- one parent, or show the same change from all but one parent for
- an Octopus merge.
+ This flag implies the '-c' option and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered uninteresting if the person merging had two versions
+ to choose between among all of the parents and the result shows
+ no changes from one of those versions.
-r::
--
1.5.6.3.549.g8ca11