gphoto-m4 ========= `gphoto-m4` is the gPhoto projects' collection of m4 macros for use with the autoconf/automake based build systems. It has been designed to be used in * `gphoto2` * `libgphoto2` * `libgphoto2_port` (located in `libgphoto2/`) * `gtkam` Some macros are re-used ones from `libexif`. Since the gPhoto project moved from SVN to git, we have not figured out yet how to properly include the `gphoto-m4` files into the respective software's `gphoto-m4/` subdirectory (either `git subtree` or `git submodule` come to mind). So for the time being, we manually update and synchronize the files. Use of `gphoto-m4` after the switch to git from SVN --------------------------------------------------- Since the gPhoto project moved from SVN to git, we have not figured out yet how to properly include the `gphoto-m4` files into the respective software's `gphoto-m4/` subdirectory. The options are: 1. Manually update (and hopefully synchronize) the files. Advantages: * No special commands needed for users or developers. Disadvantages: * The manual work for the maintainers is exhausting and error prone. 2. Use `git submodule`. Advantages: * Defined mechanism for syncing and updating the `gphoto-m4/*` files. Disadvantages: * Requires special git commands from everybody (users, developers, and maintainers) all the time (e.g. `git clone --recursive` instead of `git clone`). This is the showstopper for `git submodule`. 3. Use `git subtree`. Advantages: * Defined mechanism for syncing and updating the `gphoto-m4/*` files. * Requires no special git commands from users or developers. * Not even people actually messing with the files in `gphoto-m4/*` strictly need special commands. Only the maintainers who do the syncing and updating of the `gphoto-m4/*` files need the special commands. Disadvantages: * Requires special knowledge of special commands instead of just copying files around. The concept is less complex than copying files round, but it does require special commands. * No rebasing possible across pulls to `gphoto-m4/`. Not really necessary anyway, though. * Pushes of changes to from, say, `gphoto2/gphoto-m4` to upstream `gphoto-m4` create a lot of commit history noise in the `gphoto-m4` repository by including the complete history of the `gphoto2` repository. Note this cannot be avoided by using `git subtree split`: That is executed internally by `git subtree push`. So it appears that using `git subtree push` will push all projects' commit history into the `gphoto-m4` repo. That is if not a showstopper, then at least very ugly. For the time being, we manually update and synchronize the files. Manually syncing and updating files ----------------------------------- This section has not been written yet. Using `git submodule` --------------------- This section has not been written yet. Using `git subtree` ------------------- ### Using `gphoto-m4` as git subtree ### This section describes how to use `gphoto-m4` when it has been set up as a `git subtree` (e.g. in `gphoto2` and `libgphoto2`). Add a remote for `gphoto-m4`: git remote add origin-gphoto-m4 git@github.com:gphoto/gphoto-m4.git Pull changes to origin-gphoto-m4 into local `gphoto-m4`: git subtree pull --prefix gphoto-m4 origin-gphoto-m4 master --squash Now we can push local changes to 'gphoto-m4/*' back to `origin-gphoto-m4` as follows: git subtree push --prefix gphoto-m4 origin-gphoto-m4 master FIXME: Add more typical uses cases. ### Setting up `gphoto-m4` as git subtree ### This section describes how we initially set up `gphoto-m4` as a git subtree for `gphoto2`. This is only required once by one person, then never needs to be done by anybody else ever again. git subtree add --prefix gphoto-m4 origin-gphoto-m4 master --squash