Provided by: mrb_0.3_all bug

NAME

       gitkeeper - Mirror files between git and an installed location.

SYNOPSIS

       gk [options] pull [host]

       gk [options] push [host]

       gk [options] export git-ref [host]

DESCRIPTION

       gitkeeper is a remote administration aid.  It enables configuration files to be maintained
       locally, with a full history of changes, and synchronised on demand with a remote target
       system.  This allows files to still be altered directly on the running system, if and/or
       when that is needed, with a simple method to get that all back in sync with the archived
       copy again later.

       It uses rsync(1) and ssh(1) for all operations on the remote hosts.  No special
       configuration beyond permission to use them is required.  The use of an ssh-agent for
       managing remote logins may be an advantage though.

       At its core, gitkeeper is really just a tool for managing bidirectional mirrors, of
       potentially sparse segments of the remote filesystem, so it's not strictly limited to
       being used for configuration files, nor is it strictly dependent upon git(1) aside from
       the export option, but those are the primary uses that it was initially designed for.

COMMANDS

       pull    Pull files from the remote system into the local mirror.  This will update the
               local directory content to match the live system, but it will not commit any files
               to git or change the local index state in any way.  If you wish to commit changes
               imported in this way, you can just do that with normal git operations.

               If the host parameter is not explicitly specified, then all defined hosts will be
               pulled.

       push    Push files from the local mirror to the remote system.  This will push the state
               of the current working directory, regardless of whether the repository tree is
               currently clean or dirty.

               If the host parameter is not explicitly specified, then all defined hosts will be
               pushed.

       export  Push files from a historical snapshot of the local mirror to the remote system.
               This will do a git archive(1) export of the given git-ref to a temporary
               directory, and then perform a push operation on that tree.  It is equivalent to
               doing a git checkout of the desired ref, and then doing a push on that tree state,
               except it will respect any gitattributes you have set for what will be exported,
               and it will not change the current working directory state.

               If the host parameter is not explicitly specified, then all hosts defined in the
               exported configuration will be pushed.

OPTIONS

       -c, --config file
               The file describing what should be mirrored and how.  If not specified then
               gk.conf will be looked for in the directory that gitkeeper is invoked in.  Usually
               this should be a relative path under that location, but an absolute path is
               permitted and may be useful in some circumstances.

               If the export command is used, then this file is not read until after the export
               from git, and relative paths are resolved to files in the exported directory.
               This is usually what you want since the configuration from the exported snapshot
               will then be used.  If you need to override that for some reason then you can use
               an absolute path to an alternate configuration file.

       -l, --list
               Show the list of host aliases defined in the configuration file.  If this is used
               with the export command, then the configuration of the exported snapshot will be
               shown.

       --init  Create a skeleton configuration file.  This is a convenience to get an initial
               configuration when bootstrapping a new mirror.

       -C, --chdir directory
               Change to the given directory before running gitkeeper.  Normally you would just
               run it from the top level directory of the mirror, but this permits use from
               elsewhere in a similar way to what "make -C directory" allows.

       --destdir directory
               Prefix the remote paths to an alternate file system root.  This always changes
               only the remote path, regardless of whether a push or pull operation is being
               performed.  It acts like the "DESTDIR" option for "make install" and allows
               mirroring files to and from an alternative filesystem location but with the same
               subdirectory structure as what they would normally have.

               You can use this to export files to a chroot, or to a temporary directory
               somewhere, so that they can be examined without replacing the real files on the
               remote system.

       -u, --user
               Override the remote_user option from the configuration file for access to the
               remote host.  There probably aren't many good reasons to ever use this option,
               it's a pretty blunt hammer which will override it everywhere, but it may be useful
               for exporting a mirror to some machine or location where it isn't usually expected
               to go.

       -n, --dry-run
               Don't actually copy any files, just show what would be done if this was a live
               run.  If this is used with the export command, then the dry run will be performed
               on the requested snapshot.

       -v, --verbose
               Show more detail about what is being done.  This option may be passed multiple
               times to increase the level of verbosity even further.

               If passed along with --help then more verbose documentation will be shown.

       -?, --help
               Show this help, again.

CONFIGURATION

       The gitkeeper configuration file is expected to contain a single JSON Object, which will
       be parsed by perl's JSON::XS in its relaxed mode (which allows trailing commas after the
       final element of an array or object, and '#'-comments anywhere that whitespace would be
       permitted).

   Global options
       There is only one required member of the top level object, though other options may also
       be specified there to be inherited as defaults if not overridden for a host or one of its
       sync sets.

       hosts   The hosts member defines a JSON object in which each member is a host name alias
               that may be passed as the host parameter to gitkeeper.  The alias names are not
               used for any other purpose than as the host identifier, and may be any JSON string
               value.  No other options may be included directly in the hosts section.

        {
           "hosts": {
               "host1": { ... },
               "host2": { ... }
           }
        }

   Per-host options
       There are two required members which must be specified directly for each host alias
       object.  Other options may also be specified there which will override a global default
       for that host and be inherited as defaults for its sync sets, if not also overridden
       there.

       address The address member is a JSON string value, that defines the hostname or IP address
               used when connecting to the remote system.  It must be a valid string that can be
               passed as the host part of a remote rsync(1) path.  It should not contain a user
               part (that should instead be set with the remote_user option), but may contain a
               port specification.

       sync    The sync member is a JSON array of objects.  It must contain at least one object,
               but there is no upper bound to the number which may be included.  Each of the
               objects in the sync array define a mapping from a remote_root to a local_root, the
               paths which will be mirrored under those roots, and the rsync options which will
               be applied when transferring them.

        "host1": {
           "address": "myhost.mydomain.org",
           "sync":    [ { ... }, { ... } ]
        }

   Sync set options
       Each object in the sync array has one required member that must be specified directly in
       it.  Other options may also be specified there which will override the global and host
       defaults, and some of those options must also be defined in at least one of those places
       for each sync set.

       paths   The paths member is an array of JSON string values which specify the files and/or
               directories under the remote_root which will be mirrored with their full directory
               structure.  They may contain shell wildcards, but cannot contain brace expansions
               if the rsync --protect-args option is used.

               They must all be relative paths (ie. they must not begin with a '/').

        "sync": [
           {
               "paths": [ "file1", "dir1", "dir2/subdir", "dir3/*.conf" ]
           }
        ]

   Required options
       The following options must be defined for every sync set, though they may be configured in
       either the top level object as global defaults, in the host alias object for per-host
       defaults, or in the sync object itself.

       local_root
               A JSON string value that defines the local directory which remote paths will be
               mirrored under.  This must be a relative path, which itself is rooted to the
               directory under which gitkeeper is invoked.

               As a sanity check against accidents, this directory must already exist.

       remote_root
               A JSON string value which defines the location on the remote system that the
               specified paths are relative to.  This may be an absolute or relative path.  A
               relative path will be rooted to the home directory of the remote_user.  A value of
               "" may be used to specify the home directory of the remote_user.

   Additional options
       The following options may be defined as global or per-host defaults, or set explicitly in
       each sync set.  It is not an error for them not to be set, and a higher level default may
       be 'unset' by overriding it with an empty value.

       remote_user
               A JSON string which defines the username to use for access to the remote host.  If
               not set, then the ssh default for the remote system will be used (as configured by
               .ssh/config or similar).

       rsync_opts
               A JSON array of string values containing options to be passed to all invocations
               of rsync, for both push and pull operations.  No word splitting or shell quote
               stripping is done on the values used here, so each option must be its own array
               element.

               Note that the --relative option is passed to rsync(1) by default for all
               invocations and does not need to be included in this set.  If you really don't
               want that option for some reason, and understand the consequences of not passing
               it for this use, you can disable it with --no-relative, but there's probably no
               good reason to ever do that here.

                "rsync_opts": [ "--prune-empty-dirs",
                                "--delete-excluded",
                                "--filter=protect .s[a-w][a-z]"
                ]

       rsync_pull_opts
               Similar to rsync_opts above, but options specified in this array are appended to
               those only for pull operations.

       rsync_push_opts
               Similar to rsync_opts above, but options specified in this array are appended to
               those only for push operations.

       rsync_include
               A JSON array of string values which will be passed to rsync(1) as --include
               options.  This is a convenience which is eqivalent to adding those to rsync_opts
               ie. the following configurations would be identical in their operation if no other
               ordering constraints for the filter rules applied.

                "rsync_opts":    [ "--include=.s[a-w][a-z]/" ]
                "rsync_include": [ ".s[a-w][a-z]/" ]

       rsync_exclude
               A JSON array of string values which will be passed to rsync(1) as --exclude
               options.  This is the same as rsync_include above, except for excludes.

       rsync_filter
               A JSON array of string values which will be passed to rsync(1) as --filter
               options.  This is similar to the include and exclude options above, except it
               allows the full range of rsync filter rules to be used.

       rsync_pull_filter
               A JSON array of string values which will be passed to rsync(1) as --filter options
               (in addition to the include, exclude, and filter options above) only for pull
               operations.

       rsync_push_filter
               A JSON array of string values which will be passed to rsync(1) as --filter options
               (in addition to the include, exclude, and filter options above) only for push
               operations.

       chown   A JSON string value which will be passed to rsync as the --chown option for push
               operations to set file and directory ownership on the remote host.  If this option
               is used, the --owner and --group options will automatically added too, otherwise
               it would have no effect.  You must have superuser privilege on the remote host for
               this to work.

                "chown": "root:bind"

       chmod   A JSON string value which will be passed to rsync as the --chmod option for push
               operations to set file and directory permissions on the remote host.  If this
               option is used, the --perms option will automatically added too, otherwise it
               would have no effect.  Valid values here are anything that the rsync option would
               accept.

                "chmod": "D2755,F664"

   Pre- and Post- command hooks
       The following options may be used to execute arbitrary commands before and/or after a pull
       or push operation.  The commands are executed on the local host, in the directory that
       gitkeeper was invoked in, as the user which gitkeeper was invoked as.  They can be used to
       perform operations on the remote host by simply invoking ssh(1) or similar themselves.

       pull_pre_command
       push_pre_command
       pull_post_command
       push_post_command
               A JSON array of string values containing the command to execute and the options to
               pass to it.  This will be passed as an array to the perl system() command, so if
               the array contains multiple elements, then no word splitting or other shell
               interpretation will be performed.  If it is a single string, then it will instead
               be passed to the local shell, with all the caveats that accompany doing that.

               If the pre-command fails, then no transfer will take place.  If the transfer fails
               for some reason then the post-command will not be executed.

               That might change later if we let this get more complex and begin passing status
               and other variables to the commands that are invoked, but at this stage, that
               isn't really needed for any current use we have, so I'm not going to complicate
               things now in anticipation of what later uses might require.

FILES

       ./gk.conf
               The default configuration file.

SEE ALSO

       git(1), rsync(1), ssh(1), ssh-agent(1).

AUTHOR

       gitkeeper was written by Ron <ron@debian.org>.