Discussion:
Retro side-by-side diffs
(too old to reply)
Richard Hipp
2012-02-03 15:25:41 UTC
Permalink
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and decoration and provides plain-text output - essentially the same output
as you would get on the command-line using the -y flag. Example:

http://www.sqlite.org/src/info/21695c3476

I find the "retro" side-by-side diff to be much more readable, which is why
I am using it on the SQLite and Fossil websites, as well as on my desktop.
And I've heard no complaints from users about the retro sbsdiffs on the
website. But before I merge the retro-sbsdiff branch into trunk (and hence
purge the existing colorful sbs diff from the trunk) I thought I would as
for community feedback. Are there strong preferences one way or another?
--
D. Richard Hipp
***@sqlite.org
Lluís Batlle i Rossell
2012-02-03 15:39:49 UTC
Permalink
Post by Richard Hipp
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and decoration and provides plain-text output - essentially the same output
http://www.sqlite.org/src/info/21695c3476
I find the "retro" side-by-side diff to be much more readable, which is why
I am using it on the SQLite and Fossil websites, as well as on my desktop.
And I've heard no complaints from users about the retro sbsdiffs on the
website. But before I merge the retro-sbsdiff branch into trunk (and hence
purge the existing colorful sbs diff from the trunk) I thought I would as
for community feedback. Are there strong preferences one way or another?
Hello,

I like how it looks. I also liked the colourful, but with tuned colours (I'm a
bit used to 'meld' and its colours, for hard diffs). I definitely prefer this
retro sbs over the colourful. I don't know if the option can be given simply as
CSS styles, though. Emitting some (html tags allowing for colourful sbs is
possible?

Apart, one feature I'd like a lot is to have sbs diffs with the *option not to skip
lines*. That's usally a nice option that sbs diffs can give over unified diffs:
full context.

Regards,
Lluís.
Jan Danielsson
2012-02-03 15:47:02 UTC
Permalink
On 02/03/12 16:25, Richard Hipp wrote:
[---]
Post by Richard Hipp
Are there strong preferences one way or another?
There are two aspects I prefer with the original:
- I think color coding makes it easier to get a quick overview of
what's happened in a diff. ("I see a lot of red" is roughly
"optimizations", "I see a lot of green" is roughly "New features").
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
empty "wasted" space, due to short lines.

Those points aside, I strongly support the idea of unifying the two,
so overall I'm for the retro sbsdiff.
--
Kind regards,
Jan Danielsson
Tomek Kott
2012-02-03 16:01:13 UTC
Permalink
My preference would be to keep the color SBS diffs, at least as a skin
option or something, since I find it easier to notice changes and match
them up. Maybe somewhere in the documentation on the header / skin, there
could be css for a default coloring of the sbs diffs that one could copy
into the header?

Tomek

On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
Post by Jan Danielsson
[---]
Post by Richard Hipp
Are there strong preferences one way or another?
- I think color coding makes it easier to get a quick overview of
what's happened in a diff. ("I see a lot of red" is roughly
"optimizations", "I see a lot of green" is roughly "New features").
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
empty "wasted" space, due to short lines.
Those points aside, I strongly support the idea of unifying the two,
so overall I'm for the retro sbsdiff.
--
Kind regards,
Jan Danielsson
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jan Danielsson
2012-02-03 16:18:30 UTC
Permalink
Post by Tomek Kott
My preference would be to keep the color SBS diffs, at least as a skin
option or something, since I find it easier to notice changes and match
them up. Maybe somewhere in the documentation on the header / skin, there
could be css for a default coloring of the sbs diffs that one could copy
into the header?
The layout is so fundamentally different that it's not really
possible to do it that easily. In essence, the old sbsdiff used HTML
(tables and such), the new one essentially creates a "textfile" and
shows it in a pre-formatted section.

That said, it shouldn't be impossible to get color coding with the
new/retro version: When I started working on the original sbsdiff,
someone was afraid I was going to break their javascript solution for
getting colored unified diffs. If javascript can be used to make
uncolored unified diffs colored, then I see no reason the same couldn't
be done for side-by-side diffs.
--
Kind regards,
Jan Danielsson
Richard Hipp
2012-02-03 16:19:38 UTC
Permalink
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
Post by Jan Danielsson
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
empty "wasted" space, due to short lines.
It does as of a few moments ago. The "dw=" URI query parameter controls
column width (default 80, max 255). The "dc=" query parameter controls the
number of lines of context (default 7, max 4095). Example:

http://www.fossil-scm.org/fossil/ci/6474a92a87?sbs=1&dw=60&dc=20
--
D. Richard Hipp
***@sqlite.org
Jan Danielsson
2012-02-03 16:25:24 UTC
Permalink
On 02/03/12 17:19, Richard Hipp wrote:
[---]
Post by Richard Hipp
Post by Jan Danielsson
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
empty "wasted" space, due to short lines.
It does as of a few moments ago. The "dw=" URI query parameter controls
column width (default 80, max 255). The "dc=" query parameter controls the
http://www.fossil-scm.org/fossil/ci/6474a92a87?sbs=1&dw=60&dc=20
Excellent -- thank you.
--
Kind regards,
Jan Danielsson
Lluís Batlle i Rossell
2012-02-03 16:28:42 UTC
Permalink
Post by Tomek Kott
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
Post by Jan Danielsson
- I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
empty "wasted" space, due to short lines.
It does as of a few moments ago. The "dw=" URI query parameter controls
column width (default 80, max 255). The "dc=" query parameter controls the
http://www.fossil-scm.org/fossil/ci/6474a92a87?sbs=1&dw=60&dc=20
Great! dc=-1 seems to work for full context though, in a quick check. :) I can't
tell if does more than 4095, in that page.

Regards,
Lluís.
Matt Welland
2012-02-03 16:04:00 UTC
Permalink
Post by Richard Hipp
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and decoration and provides plain-text output - essentially the same output
http://www.sqlite.org/src/info/21695c3476
I find the "retro" side-by-side diff to be much more readable, which is
why I am using it on the SQLite and Fossil websites, as well as on my
desktop. And I've heard no complaints from users about the retro sbsdiffs
on the website. But before I merge the retro-sbsdiff branch into trunk (and
hence purge the existing colorful sbs diff from the trunk) I thought I
would as for community feedback. Are there strong preferences one way or
another?
I will miss the colors as I tend to rely on color in tools like tkdiff,
meld and xxdiff to give me a big picture view and to draw my eye to the
changes. The compressed summary (in the center scroll bar in tkdiff and on
the rhs in meld is extremely useful but I doubt that can be easily
replicated in fossil so maybe keeping it simple in the browser and leaving
the more powerful interface to external tools makes sense.

Just my $0.02
Post by Richard Hipp
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Andreas Kupries
2012-02-03 16:56:58 UTC
Permalink
Post by Richard Hipp
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors and
decoration and provides plain-text output - essentially the same output as you
http://www.sqlite.org/src/info/21695c3476
I find the "retro" side-by-side diff to be much more readable, which is why I
am using it on the SQLite and Fossil websites, as well as on my desktop. And
I've heard no complaints from users about the retro sbsdiffs on the website.
But before I merge the retro-sbsdiff branch into trunk (and hence purge the
existing colorful sbs diff from the trunk) I thought I would as for community
feedback. Are there strong preferences one way or another?
(At this point I haven't looked at all the other responses which seem to have
gotten in in the half hour I was walking to the office)

Looking at the new retro-look and the color look side-by-side (*, sic) I
strongly prefer the colorized sbs. If I could have only one that would be the
one I would go for. If both looks get their own strong following then it might
be advisable to have an admin setting in the repository to choose which of the
looks to show.

(Ad *): http://core.tcl.tk/tk/ci/1cb7c1e06a?sbs=1
--
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™

P: 778.786.1122
F: 778.786.1133
***@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
Richard Hipp
2012-02-03 17:02:27 UTC
Permalink
On Fri, Feb 3, 2012 at 11:56 AM, Andreas Kupries
Post by Richard Hipp
Post by Richard Hipp
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors and
decoration and provides plain-text output - essentially the same output as you
http://www.sqlite.org/src/**info/21695c3476<http://www.sqlite.org/src/info/21695c3476>
I find the "retro" side-by-side diff to be much more readable, which is why I
am using it on the SQLite and Fossil websites, as well as on my desktop.
And
I've heard no complaints from users about the retro sbsdiffs on the website.
But before I merge the retro-sbsdiff branch into trunk (and hence purge
Post by Richard Hipp
the
existing colorful sbs diff from the trunk) I thought I would as for community
feedback. Are there strong preferences one way or another?
(At this point I haven't looked at all the other responses which seem to
have gotten in in the half hour I was walking to the office)
Looking at the new retro-look and the color look side-by-side (*, sic) I
strongly prefer the colorized sbs. If I could have only one that would be
the one I would go for. If both looks get their own strong following then
it might be advisable to have an admin setting in the repository to choose
which of the looks to show.
The design of the diff system is such that it would be a major (and
undesirable) change to provide support for both side-by-side diff formats.
Post by Richard Hipp
(Ad *): http://core.tcl.tk/tk/ci/**1cb7c1e06a?sbs=1<http://core.tcl.tk/tk/ci/1cb7c1e06a?sbs=1>
--
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
P: 778.786.1122
F: 778.786.1133
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/**
stackato <http://www.activestate.com/stackato>
______________________________**_________________
fossil-users mailing list
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
--
D. Richard Hipp
***@sqlite.org
Remigiusz Modrzejewski
2012-02-03 17:31:51 UTC
Permalink
Post by Richard Hipp
I find the "retro" side-by-side diff to be much more readable, which is why
I am using it on the SQLite and Fossil websites, as well as on my desktop.
And I've heard no complaints from users about the retro sbsdiffs on the
website. But before I merge the retro-sbsdiff branch into trunk (and hence
purge the existing colorful sbs diff from the trunk) I thought I would as
for community feedback. Are there strong preferences one way or another?
I'm for color-coded. All of the reasons have already been listed in the thread.


Kind regards,
Remigiusz Modrzejewski
Weber, Martin S
2012-02-03 17:33:42 UTC
Permalink
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.

-Martin
Stephan Beal
2012-02-03 17:40:56 UTC
Permalink
Post by Weber, Martin S
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the thread.
Same here.
If not color coded, perhaps adding add/change/remove markers to the _start_
of each line, since that would make JS-scripting the colorification
relatively simple? (Loop over the lines, do a regex check on the start
(change type + line number), and wrapping the affected line(s) in a styled
span.)

:-?
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Tomek Kott
2012-02-03 18:06:19 UTC
Permalink
I'd be happy with Stephan's suggestion, since it would satisfy both parties
with a little work on the colorizing side. I think the only additional
point is to have the <div> or whatever surrounds the code to have a good
descriptive class we can latch on to with JS.

Tomek
Post by Stephan Beal
Post by Weber, Martin S
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the thread.
Same here.
If not color coded, perhaps adding add/change/remove markers to the
_start_ of each line, since that would make JS-scripting the colorification
relatively simple? (Loop over the lines, do a regex check on the start
(change type + line number), and wrapping the affected line(s) in a styled
span.)
:-?
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jan Danielsson
2012-02-03 19:17:15 UTC
Permalink
Post by Stephan Beal
Post by Weber, Martin S
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the thread.
Same here.
If not color coded, perhaps adding add/change/remove markers to the _start_
of each line, since that would make JS-scripting the colorification
relatively simple? (Loop over the lines, do a regex check on the start
(change type + line number), and wrapping the affected line(s) in a styled
span.)
I wouldn't like that change very much. I think the way < and > are
used now is very intuitive, and it creates a nice separator column with
relevant meta data. I think it would be changing something which is more
intuitive to something less intuitive (for the human reader), just to
make it easier to regexp, which I don't really like.

With that being said, it's just a personal preference, and not
something I'd put up a fight against.

Though it occurs to me that if almost everyone will anyways be
sticking colorized diffs into their fossil repositories via javascript
hacks, then perhaps it should be able to output them without any
additions. :-/ When I started working on side-by-side diffs it was
suggested to me that it could be done using javascript instead, but I
thought to myself "If everyone is going to be pasting these javascripts
(or references to them) into every project they have, it's the sort of
feature fossil should handle itself.".

How much work would it be to put together a proof-of-concept sbsdiff
colorizer? (I would do it myself, but I'm sorry to say my javascript-fu
is so weak that I wouldn't even be able to assist anyone wanting to take
on the project).
--
Kind regards,
Jan Danielsson
Stephan Beal
2012-02-03 19:33:41 UTC
Permalink
On Fri, Feb 3, 2012 at 8:17 PM, Jan Danielsson
Post by Jan Danielsson
I wouldn't like that change very much. I think the way < and > are
used now is very intuitive, and it creates a nice separator column with
i agree but having them in the middle makes it literally impossible to
reliably determine where/what the change-markers are using script code
because they can be syntactically ambiguous with content.

How much work would it be to put together a proof-of-concept sbsdiff
Post by Jan Danielsson
colorizer?
The new diffs can't reliably be colored using JS because of potential
syntactic ambiguities. It would work "often" but not "always."
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Lluís Batlle i Rossell
2012-02-03 19:39:25 UTC
Permalink
Post by Jan Danielsson
How much work would it be to put together a proof-of-concept sbsdiff
Post by Jan Danielsson
colorizer?
The new diffs can't reliably be colored using JS because of potential
syntactic ambiguities. It would work "often" but not "always."
The sbs diffs come by a '<pre>' and the dump of diffs in text form,
without any browser-friendly semantic information.

I imagine that a similar look could be achieved with tags in the middle, instead
of '<pre>', and CSS. Fossil knows the semantic information of any symbol it
outputs at the time of sbs diff, and it could add or not add the tags depending
on ui or console behaviour.

Those tags could have meanings for the browser, so it could use CSS to make them
look like Richard likes, or like others may like. Would this be enough? Maybe
Richard also relies on some ability to 'copy-and-paste' that text, that thus
could be broken using the tags.

What's bad in using a combination of tags and css in the ui output? The code in
fossil looks too complex for too little win? Or simply noone wrote it still?

Regards,
Lluís.
a***@mail.com
2012-02-04 10:08:33 UTC
Permalink
Same here. I like the colorful diff.

But I would like to know (sorry if I missed) what's th eproblem with color sbs and what are we getting with retro sbs?

- Altu
----- Original Message -----
From: Weber, Martin S
Sent: 02/03/12 11:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Retro side-by-side diffs
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
-Martin
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2012-02-04 12:24:29 UTC
Permalink
Post by a***@mail.com
Same here. I like the colorful diff.
But I would like to know (sorry if I missed) what's the problem with color
sbs and what are we getting with retro sbs?
Here is an example, two different websites showing the same Fossil project
(TCL), one with the traditional colorful diff and the other with the new
retro diff:

(1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
(2) http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67

The change of this check-in is a single line of code - indeed a single
character on that one line. With (1), my eyes are distracted by a bunch of
needless coloration, and I have to stare at the screen for a second or two
before I can discern what has actually changed. I tried using colored
diffs for a while, but I eventually gave up in frustration. They are
simply not useful to me. I can read the old-style unified diffs faster. In
(2), on the other hand, I can clearly and immediately see that one line has
changed. The change "pops" out at me. I don't have to think about it - it
is just there.
Post by a***@mail.com
- Altu
----- Original Message -----
From: Weber, Martin S
Sent: 02/03/12 11:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Retro side-by-side diffs
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
-Martin
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
***@sqlite.org
Ramon Ribó
2012-02-04 13:36:31 UTC
Permalink
For me, much better with the colors. Maybe taking out the violet of the
hidden lines.
It helps a lot to focus the attention to the correct place.

RR
Post by Richard Hipp
Post by a***@mail.com
Same here. I like the colorful diff.
But I would like to know (sorry if I missed) what's the problem with
color sbs and what are we getting with retro sbs?
Here is an example, two different websites showing the same Fossil project
(TCL), one with the traditional colorful diff and the other with the new
(1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
(2) http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
The change of this check-in is a single line of code - indeed a single
character on that one line. With (1), my eyes are distracted by a bunch of
needless coloration, and I have to stare at the screen for a second or two
before I can discern what has actually changed. I tried using colored
diffs for a while, but I eventually gave up in frustration. They are
simply not useful to me. I can read the old-style unified diffs faster. In
(2), on the other hand, I can clearly and immediately see that one line has
changed. The change "pops" out at me. I don't have to think about it - it
is just there.
Post by a***@mail.com
- Altu
----- Original Message -----
From: Weber, Martin S
Sent: 02/03/12 11:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Retro side-by-side diffs
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
-Martin
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Matt Welland
2012-02-04 14:01:46 UTC
Permalink
Seconded. The hidden lines receive more emphasis than the change. Do a
tkdiff on the same change and it is immediately obvious what the change is.
I checked meld, tkdiff and xxdiff and in all of them the actual character
that was removed is also highlighted making it immediately obvious what
changed. It was not immediately obvious to me what changed in either the
colored or retro examples. If fossil can't easily match the capability of
an external tool then my vote would be to go with the retro.
Post by Ramon Ribó
For me, much better with the colors. Maybe taking out the violet of the
hidden lines.
It helps a lot to focus the attention to the correct place.
RR
Post by Richard Hipp
Post by a***@mail.com
Same here. I like the colorful diff.
But I would like to know (sorry if I missed) what's the problem with
color sbs and what are we getting with retro sbs?
Here is an example, two different websites showing the same Fossil
project (TCL), one with the traditional colorful diff and the other with
(1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
(2) http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
The change of this check-in is a single line of code - indeed a single
character on that one line. With (1), my eyes are distracted by a bunch of
needless coloration, and I have to stare at the screen for a second or two
before I can discern what has actually changed. I tried using colored
diffs for a while, but I eventually gave up in frustration. They are
simply not useful to me. I can read the old-style unified diffs faster. In
(2), on the other hand, I can clearly and immediately see that one line has
changed. The change "pops" out at me. I don't have to think about it - it
is just there.
Post by a***@mail.com
- Altu
----- Original Message -----
From: Weber, Martin S
Sent: 02/03/12 11:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Retro side-by-side diffs
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in
the
Post by Remigiusz Modrzejewski
thread.
Same here.
-Martin
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Peter Spjuth
2012-02-04 14:09:36 UTC
Permalink
Fully agree, the colored one suffers from being cluttered. If the
retro one grayed
the changed line to slightly highlight it, it would help a lot.

Shameless plug: Diff tool with built in Fossil support:
http://eskil.tcl.tk/index.html/doc/trunk/htdocs/fossil.wiki

/Peter
Post by Matt Welland
Seconded. The hidden lines receive more emphasis than the change. Do a
tkdiff on the same change and it is immediately obvious what the change is.
I checked meld, tkdiff and xxdiff and in all of them the actual character
that was removed is also highlighted making it immediately obvious what
changed. It was not immediately obvious to me what changed in either the
colored or retro examples. If fossil can't easily match the capability of an
external tool then my vote would be to go with the retro.
Post by Ramon Ribó
For me, much better with the colors. Maybe taking out the violet of the
hidden lines.
It helps a lot to focus the attention to the correct place.
RR
Post by Richard Hipp
Post by a***@mail.com
Same here. I like the colorful diff.
But I would like to know (sorry if I missed) what's the problem with
color sbs and what are we getting with retro sbs?
Here is an example, two different websites showing the same Fossil
project (TCL), one with the traditional colorful diff and the other with the
  (1)  http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
  (2)  http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
The change of this check-in is a single line of code - indeed a single
character on that one line.  With (1), my eyes are distracted by a bunch of
needless coloration, and I have to stare at the screen for a second or two
before I can discern what has actually changed.  I tried using colored diffs
for a while, but I eventually gave up in frustration.  They are simply not
useful to me.  I can read the old-style unified diffs faster. In (2), on the
other hand, I can clearly and immediately see that one line has changed.
The change "pops" out at me.  I don't have to think about it - it is just
there.
Post by a***@mail.com
- Altu
----- Original Message -----
From: Weber, Martin S
Sent: 02/03/12 11:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Retro side-by-side diffs
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
-Martin
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Martin Gagnon
2012-02-04 14:00:36 UTC
Permalink
The problem here is the violet for skipped lines that is more outstanding than the diff itself. I'm sure the colorful version can be tweaked to have the best of both world.

In my case, 80% of the case, I prefer unified (with color via JS even more). Especially when there's not a lot of changes in a line. With sbs diff, the 2 versions are far away, it' hard to see the diff. With unified, you can see right away, the 2 lines are one next to the other.

More advanced diffs programs (meld, vimdiff etc..) solve that by highlighting what is different in the line. That's become a lot more complex.
Post by a***@mail.com
Same here. I like the colorful diff.
But I would like to know (sorry if I missed) what's the problem with color sbs and what are we getting with retro sbs?
(1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
(2) http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
The change of this check-in is a single line of code - indeed a single character on that one line. With (1), my eyes are distracted by a bunch of needless coloration, and I have to stare at the screen for a second or two before I can discern what has actually changed. I tried using colored diffs for a while, but I eventually gave up in frustration. They are simply not useful to me. I can read the old-style unified diffs faster. In (2), on the other hand, I can clearly and immediately see that one line has changed. The change "pops" out at me. I don't have to think about it - it is just there.
- Altu
----- Original Message -----
From: Weber, Martin S
Sent: 02/03/12 11:03 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Retro side-by-side diffs
Post by Remigiusz Modrzejewski
I'm for color-coded. All of the reasons have already been listed in the
thread.
Same here.
-Martin
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
--
Martin G.
Leo Razoumov
2012-02-04 15:24:24 UTC
Permalink
Post by Richard Hipp
Here is an example, two different websites showing the same Fossil project
(TCL), one with the traditional colorful diff and the other with the new
  (1)  http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
  (2)  http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
Retro diff (2) looks really bad in Google Chrome-16 and in
Firefox-3.6.24, see attached chrome screen-shot (Ubuntu-10.04).

--Leo--
Richard Hipp
2012-02-04 15:36:30 UTC
Permalink
Post by Jan Danielsson
Post by Richard Hipp
Here is an example, two different websites showing the same Fossil
project
Post by Richard Hipp
(TCL), one with the traditional colorful diff and the other with the new
(1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
(2) http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
Retro diff (2) looks really bad in Google Chrome-16 and in
Firefox-3.6.24, see attached chrome screen-shot (Ubuntu-10.04).
Huh. On Ubuntu 11.10 running the latest Firefox sources (compiled just
this morning) it looks fine: Loading Image...

Can anybody explain the difference? Is there something wrong with the CSS?
Post by Jan Danielsson
--Leo--
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
***@sqlite.org
Leo Razoumov
2012-02-04 18:37:47 UTC
Permalink
Post by Leo Razoumov
Post by Richard Hipp
Here is an example, two different websites showing the same Fossil project
(TCL), one with the traditional colorful diff and the other with the new
  (1)  http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
  (2)  http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1&dw=67
Retro diff (2) looks really bad in Google Chrome-16 and in
Firefox-3.6.24, see attached chrome screen-shot (Ubuntu-10.04).
Huh.  On Ubuntu 11.10 running the latest Firefox sources (compiled just this
morning) it looks fine:  http://www.fossil-scm.org/ss1.gif
Can anybody explain the difference?  Is there something wrong with the CSS?
My screen shot was for google chrome-16.0.912.63.

--Leo--
Leo Razoumov
2012-02-05 20:30:08 UTC
Permalink
Post by Leo Razoumov
Retro diff (2) looks really bad in Google Chrome-16 and in
Firefox-3.6.24, see attached chrome screen-shot (Ubuntu-10.04).
Huh.  On Ubuntu 11.10 running the latest Firefox sources (compiled just this
morning) it looks fine:  http://www.fossil-scm.org/ss1.gif
Can anybody explain the difference?  Is there something wrong with the CSS?
I played a bit with Firefox-10 on Linux. I seem to get a good layout
when set font-sizes in Preferences to 12pt.
When, on the other hand, I increase font sizes to 16 or 18pt then the
layout got messed up.
I am using hi-res monitor and 12pt is really small. I know very little
about CSS. Is it possible to make a layout that does not break when a
user changes default font size??

--Leo--

Jan Danielsson
2012-02-04 12:33:12 UTC
Permalink
Post by a***@mail.com
Same here. I like the colorful diff.
But I would like to know (sorry if I missed) what's th eproblem with color sbs and what are we getting with retro sbs?
The reason is that we have two different places in the code which do
the same thing (create side-by-side diffs), but they do it in different
ways.

Having them consolidated has benefits. (Smaller binary, much easier
to maintain, adding/changing features only requires it to be done in one
place, etc). The original sbsdiff was hard-coded for html (it will not
translate to the console), the retro sbsdiff works for both console and
displaying it in a <pre> html-section.
--
Kind regards,
Jan Danielsson
Continue reading on narkive:
Loading...