Some ideas for idiot-proofing

[deerdrop]

Hello, I very nearly made a terrible blunder, and I wanted to provide some insight on how this could be avoided.
First and foremost, I believe there should be a default logfile location. If I do not specify the creation of a logfile and do not pipe stdout anywhere, I immediately lose a ton of information as stdout rocketed past the ~1000 line buffer of my terminal. (I understand this is a bit lower line count than typical but it's the default for Yakuake and it hasn't been a problem before.)
Secondly, those logs would still not be very helpful to me had a mistake occurred, as even the verbose output does not specify whether a file has been created or modified. As far as I can tell the double-verbose output does not include this information either. It would be difficult enough to undo my hypothetical mistakes with access to this information, but lacking it makes that nearly impossible.
(Can you tell I made minor edits to this after realizing I had not committed a horrible error? Maybe I would have noticed sooner that I hadn't messed up if I had logs to examine.)
On a related note, I think the phrasing "The default handling of symlinks is to recreate each symlink's unchanged value on the receiving side." in the manpage is a bit... unhelpful. I'm not sure what phrasing would be better but I had to read that several times to realize "unchanged" actually meant unchanged relative path.

[frukto]

Are you a aware of --itemize-changes (-i) and --dry-run (-n)? I almost always inspect the first lines of the output of rsync -ni (piping to a log ) before firing the final command.

Regarding the symlinks:

The default handling of symlinks is to recreate ...

refers to the SYMBOLIC LINK section which is very clear:

... the default handling is to recreate them with the same target on the destination

[deerdrop]

Yes, I did discover those options in my hunt for a solution. If I hadn't been a little bit of an idiot, I wouldn't have titled this conversation like I did.

... the default handling is to recreate them with the same target on the destination.

That seems like much clearer phrasing to me. Are you saying that line is already in the manual somewhere? Maybe that could replace the line I pointed out. Redundancy is not a bad thing in documentation.

[frukto]

Yes, it is already in the docs.