Patrick Rutkowski wrote:
> I also don't want to have to manually make sure that foo.cfg is
> synced among all three projects.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html