Show 38 quoted lines
> I just did an arm merge that needed some (very trivial) manual fixups
> (commit ID cce0cac1, in case anybody cares).
>
> As usual, git-diff-tree --cc does a beautiful job on it, but I also
> checked the gitweb output, which seems to not do as well (the commit
> message about a manual conflict merge doesn't make any sense at all).
>
> Now, in this case, what gitweb shows is actually "sensible": it will show
> the diff of what the merge "brought in" to the mainline kernel, and in
> that sense I can certainly understand it. It basically diffs the merge
> against the first parent.
>
> So looking at that particular example, arguably gitweb does something
> "different" from what the commit message is talking about, but in many
> ways it's a perfectly logical thing.
>
> However, diffing against the first parent, while it sometimes happens to
> be a sane thing to do, really isn't very sane in general. The merge may go
> the other way (subdevelopers merging my code), like in commit b2faf597,
> and sometimes there might not be a single reference tree, but more of a
> "couple of main branches" approach with merging back and forth). Then the
> current gitweb behaviour makes no sense at all.
>
> So it would be much nicer if gitweb had some alternate approach to showing
> merge diffs. My suggested approach would be to just let the user choose:
> have separate "diff against fist/second[/third[/..]] parent" buttons. And
> one of the choices would be the "conflict view" that git-diff-tree --cc
> gives (I'd argue for that being the default one, because it's the only one
> that doesn't have a "preferred parent").
>
> Kay?
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>