Re: gplv3 files and updates

[Bruno Haible]

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