Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Fri, 10 Feb 2012, Michał Kiedrowicz wrote: > > Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > > Michał Kiedrowicz <michal.kiedrowicz@xxxxxxxxx> writes: > > > > > > > The code that comares lines is based on > > > > contrib/diff-highlight/diff-highlight, except that it works with > > > > multiline changes too. It also won't highlight lines that are > > > > completely different because that would only make the output unreadable. > > > > Combined diffs are not supported but a following commit will change it. > > > > > > I was thinking that if gitweb were to support "diff refinement > > > highlighting", it would either use one of *Diff* packages from CPAN, > > > or "git diff --word-diff" output. > > > > I think highlighting inline and side-by-side diff outputs is > > something different from "git diff --word-diff". I find it useful for > > people who are used to these diff formats (i.e. me :). > > I was thinking about *using* "git diff --word-diff" for diff refinement > highlighting of inline (unified) and side-by-side diff... > Then I must have misunderstood you. > though having an option of showing word-diff would be I think a good > idea in some cases, like e.g. documentation changes. > > > OTOH I'm not against using a dedicated package from CPAN. But I think > > my approach is proven to work (I use contrib/diff-highlight as a > > filter) and more lightweight (doesn't add another dependency to > > gitweb). Moreover, adding support for some Diff package may be done > > later, at any moment. It's just a matter of replacing one function > > (format_rem_add_line()) with the one that uses Diff. > > O.K., if it is tested code, then all is good. As I wrote, I haven't taken the code as-is (for example, original code only works for oneline changes). But the general approach is the same. > Well, except the fact > that I'm rather wary about adding more code to gitweb when it is still > single monolithic script, rather than split into packages. > Yeah, jumping between 2k'th and 5k'th line isn't a great fun. Do you have any roadmap how to split gitweb? > Anyway, I'll try to review those patches soon. I like the refactoring > work (that is from what I had chance to examine). Thanks. -- 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