On May 2, Jakub Narebski wrote:
>
> Well, the compact combined output is thought in such way that "git
> diff --cc" should be empty except for evil merges, when change comes
> from neither of parents. See description of --cc format in
> git-diff(1) manpage.
Is there a way to convince `git diff' to show *only* these diffs?
Hopefully something that will also play with --stat... Actually, I'm
fine with `git show' instead -- and it does show these things, but if
I add a --stat it shows all changed files again.
On May 2, Jonathan Nieder wrote:
>
> diff --name-only follows exactly the example heuristic you
> described. It still does not catch all manual merge resolutions[1].
>
> Sometimes two branches introduce different changes to completely
> separate parts of a file. This is not a conflict, and diff --cc
> will correctly report the merge as trivial (whereas diff --name-only
> does not pay enough attention to do the same).
Good -- the first paragraph is what I thought it would do, the second
makes it even better. Perhaps it would be nice to show such manual
reoslutions from one parent, but I think that that certainly qualifies
as stuff that is much less interesting than work that was done to
combine content inside a file, or one of those evil merges. (Since
it's a notification script -- so I really want it to highlight only
"real" work that was done.)
> On the other hand, sometimes two branches introduce conflicting
> changes, but the correct resolution for each conflict hunk is to
> pick one as winner. Though simple, this can be error-prone, because
> rejecting one change from branch A might end up breaking another
> change that was accepted from the same branch. diff --cc examines
> only the selected revision and its parents and for all it knows,
> this is just another trivial merge.
To translate the "danger" here, I think that if one person commits
some changed files, another one does a merge with the earlier content
and essentially re-commits all previous versions -- undoing this
commit -- IIUC, then in this case my strategy wouldn't show anything.
I think that what I do would work "well enough", since such things
would be rare to do (eg, it makes more sense to merge first, then
another commit that undoes the changes), and in any case there's also
the overall push diff, and those changes would show up there.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html