* [RFC] How to show merge commits in gitweb?
2007-05-17 10:39 Glossary: trivial, clean, evil merge Jakub Narebski
@ 2007-05-26 23:10 ` Jakub Narebski
0 siblings, 0 replies; 2+ messages in thread
From: Jakub Narebski @ 2007-05-26 23:10 UTC (permalink / raw)
To: git
I have asked questions cited below (with no answer as of yet) because
I needed to have terminology right when describing merge commits diff
in gitweb.
People asked that 'commitdiff' view in gitweb used compact combined
(--cc) and not more verbose combined (-c) format for merges. The
problem lies in the fact that due to chunk simplification for `--cc'
some patches might be dropped completely from the patchset part, while
respective line is still present in the difftree/raw format part; the
difftree/raw part is the same for `-c' and for `--cc'. Because difftree
(whatchanged-like) has inner (anchor) links to respective patch (part
of patchset) there is problem what to do for lines which have no
corresponding patch (because it got simplified).
git-diff-tree(1):
[...]
--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
hunks disappear, the commit itself and the commit log
message is not shown, just like in any other "empty diff" case.
One solution is for gitweb to add fake missing patches, with the message
(in the place of patch body, or in extended diff header) that the diff
is empty: for example "Clean merge"... although empty `--cc' patch does
not need to mean clean merge, see below.
Other solution would be to change raw output format for "diff --cc",
or change difftree body output, which would need parsing patchset first.
P.S. By the way, should gitweb output `-c' diff if `--cc' patchset
output is empty, and to "show from which parent file came from" based
on `-m' output if `-c' output is empty (on tree-level / trivial
merges)?
On Thu, 17 May 2007, Jakub Narebski wrote:
> What is the definition of a trivial merge? Is it tree-level merge, for
> which git-diff -c output would be empty?
Trivial merge means that changes occured only on one branch, and we take
result from this branch; see Documentation/technical/trivial-merge.txt
Tree-level merge means that the result is taken from one of the parents.
I think that while trivial merge is tree-level merge, they do not
necessary mean the same: the result of merge using 'theirs' strategy is
tree-level merge, but not trivial merge. The same in the case of
conflicts resolved to the version from one of the parents.
"git diff -c" output is empty for tree-level merge.
> What is the definition of clean merge? Is it merge without conflicts?
> How to name merge for which git-diff --cc output is empty: simple
> merge perhaps? I think it does not need to be clean merge in the "no
> conflicts" meaning.
IMHO clean merge is a merge in which there can be file-level conflicts,
but they resolve cleanly. Clean merge is I think a merge in which
change in a chunk comes always from one of the parents (we can have non
tree-level merge only for merging two branches, not for an octopus),
but not all merges which have "git diff --cc" output empty are clean
merges.
BTW. the fact that merge resolves cleanly, without need for manual
intervention, depends in git also on what do you have in rr-cache
(recorded resolutions).
> What is the definition of evil merge? Is it merge for which merge
> commit is different from all the parents? How to name merge for which
> git-diff --cc output is non empty, then?
evil merge::
An evil merge is a merge that introduces changes that
do not appear in any parent.
But not only evil merges can have "git diff --cc" output non-empty.
Summary: merges for which "git diff -c" is empty are tree-level merges,
usually trivial merges; merges for which "git diff --cc" is empty are
simple merges, usually clean merges.
Please correct me if I'm wrong. TIA.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 2+ messages in thread