git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: [RFC] How to show merge commits in gitweb?
Date: Sun, 27 May 2007 01:10:37 +0200	[thread overview]
Message-ID: <200705270110.37493.jnareb@gmail.com> (raw)
In-Reply-To: <200705171239.24300.jnareb@gmail.com>

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

      reply	other threads:[~2007-05-26 23:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-17 10:39 Glossary: trivial, clean, evil merge Jakub Narebski
2007-05-26 23:10 ` Jakub Narebski [this message]

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=200705270110.37493.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /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 NNTP newsgroup(s).