Re: Sharing a file between projects

Patrick Rutkowski wrote:

Give foo.cfg its own repo, since it seems it is independently useful. Then you could use it from your other projects P1, P2, P3 in one of the following ways:

a. Installation script (‘make install’) copies foo.cfg to some
   standard filename, such as /usr/share/foo/foo.cfg or /etc/foo.cfg.

   Then use it from there, e.g. by tracking an ordinary symlink
   /etc/foo.cfg -> foo.cfg in the P1, P2, P3 trees.

b. Occasionally pull from the foo.cfg project into P1, P2, and P3.

c. Teach P1, P2, P3 build scripts to clone the foo.cfg repo and grab
   foo.cfg

d. Add the foo.cfg repo as a submodule of the P1, P2, and P3 repos.

Examples:

 a. most libraries.  I guess /usr/lib/tclConfig.sh and
    /usr/lib/pkgconfig/* are good examples.
 b. Debian X build system: http://git.debian.org/?p=pkg-xorg/xsfbs.git
 d. gnulib: http://git.savannah.gnu.org/cgit/gnulib.git/tree/users.txt

Relevant git features:

 a. If there is a symlink in the worktree, the only information that
    git will notice is “symlink to <target>”.  The content of the
    target does not enter the tracked tree.

 b. Merging from an independent project is a perfectly okay way to add
    files.  Merging again is a good way to update them.

    Merging changes back to a smaller project is not so well
    supported[1].

 d. Using submodules works like this:

    . ‘git clone --recursive’ to grab all the relevant files at once

    . Do work within submodules and ‘git push’ to publish your work

    . Git will remember the ‘last tested commit’ so new changes to
      foo.cfg do not break new clones of P1, P2, and so on until
      someone in each project explicitly acks them.

    . See git-submodule(1) for details (and please let us know about
      confusing or missing details in that manual).

Thoughts? Jonathan

[1] Suppose I have been working for a while as in case (b) above [time flows from left to right]:

 foo.git:    F --- G --- H --- I
                    \           \
 P1: A --- B --- C - M --- D --- N --- O

Now I make a change to foo.cfg (Q) and commit and push it in P1.git, even though it ought to have been done in foo.git so it could be used by P2 and P3, too. Oops.

 foo.git:    F --- G --- H --- I
                    \           \
 P1: A --- B --- C - M --- D --- N --- O --- Q

Now I could try to merge P1 into foo.git, but unfortunately the result would be a commit incorporating all development from both branches, including the files from P1 that are _not_ foo.cfg.

I use git-filter-branch(1) to recover, producing an alternate history tracking only changes to foo.cfg:

      F --- G --- H --- I
             \           \
        A' ---M'----------N' --- Q'

Uh, the desired history looks more like the following:

     F --- G --- H --- I --- Q'

but git filter-branch --prune-empty is not sophisticated enough to do that. Maybe someone can chime in with a script for this situation.

Now I merge the rewritten history into foo.git:

 foo.git:    F --- G --- H --- I --- Q'
                    \           \
 P1: A --- B --- C - M --- D --- N --- O --- Q

and use ‘merge -s ours’ to indicate that the new changes have already been incorporated into P1.

 foo.git:    F --- G --- H --- I ------ Q' ---.
                    \           \              \
 P1: A --- B --- C - M --- D --- N --- O --- Q - R