I incorrectly assumed that an rsync push/pull without the -p flag would work similar to a git push/pull, and that new files would have full permissions minus the umask.

However, even without the -p flag, rsync still preserves the source file's permissions. The -p flag merely instructs rsync to (attempt to) ignore the receiver's umask.

As per man rsync:

New files get their "normal" permission bits set to the source file's
permissions masked with the receiving end's umask setting, and their
special permission bits disabled except in the case where a new
directory inherits a setgid bit from its parent directory.

Better yet, there's a simple suggestion for how to create a flag that ignores source permissions:

To give new files the destination-default permissions (while leaving
existing files unchanged), make sure that the --perms option is off
and use --chmod=ugo=rwX (which ensures that all non-masked bits get
enabled). If you'd care to make this latter behavior easier to type,
you could define a popt alias for it, such as putting this line in the
file ~/.popt (this defines the -s option, and includes --no-g to use
the default group of the destination dir):

rsync alias -s --no-p --no-g --chmod=ugo=rwX

You could then use this new option in a command such as this one:

rsync -asv src/ dest/

(Caveat: make sure that -a does not follow -s, or it will re-enable
the --no-* options.)

The umask is a filter not a setting. On other words it limits the permission bits that can be set for files (and directories). It doesn't force or require that any permissions get set, only that certain bits cannot be set.

If you need group write to be set, you may need to run chmod after the rsync.

Since there's a -p option described as "preserve permissions", I assumed omitting -p would not preserve source permissions. It turns out this is wrong! Thanks for leading me in the right direction.
–
Aaron AdamsAug 23 '13 at 17:44