Hi Paul,
> If this sort of bootstrap were changed to make copies rather than
> symbolic links, it would be much more of a pain to develop when
> changes to both gnulib and an application are being debugged. It
> would be far too easy to mistakenly edit the coreutils copy of a
> gnulib file rather than the original; and later, when everything is
> checked in, some of the gnulib fixes would be lost.
An alternative approach would be to rely on a versioning system which
supports easy branching, like git. Here is a rough idea how this could
work:
Use three branches
- master = the code which you pull and push from/to the public repository.
- autogened = the code, augmented with files from gnulib and (optionally)
other files brought in by autopoint, automake etc.
- work = the code you work on.
The branches 'autogened' and 'work' are private - they exist only in your
local repository.
# Creating the autogened branch:
git-branch autogened
git-checkout autogened
./bootstrap --gnulib-srcdir=/my/gnulib --copy --skip-po
junk=`find . -name .gitignore`
rm -f $junk
git-commit $junk
git-add
git-commit
# Creating the work branch:
git-branch work
git-checkout work
# Doing some work:
vi lib/xalloc.h
git-commit lib/xalloc.h
# Determining diffs to push into gnulib:
git-diff autogened work
# Patch your local gnulib copy.
# Updating from gnulib:
git-checkout autogened
# Modify bootstrap so that it does not say "lib/xalloc.h overrides
._bootmp/lib/xalloc.h"
./bootstrap --gnulib-srcdir=/my/gnulib --copy --skip-po
rm -f ./lib/config.hin~
git-add
git-update-index lib/xalloc.h
git-commit
# Back to work:
git-checkout work
git-rebase autogened
In the current state, the set of commands to use is so complicated that
I wouldn't use it myself: I have not much experience with git.
Can someone simplify this and polish the rough edges?
Bruno
