bootstrap/autogen.sh and git submodules

bootstrap/autogen.sh and git submodules

[Bruno Haible]

Hi,

When gnulib is used in a package, often the maintainers of that package
use it via a git submodule, because that enables them to upgrade to newer
versions of gnulib when they want to (and have a failsafe build between
these upgrades), rather than having to adapt to gnulib changes at any moment.
Even if it's only the imported file list which has changed, which might
require an update to the package's .gitignore file.

The use of git submodules, however, has three problems:

  1) There are two use-cases of bootstrap/autogen.sh (the name does not matter):
       - first-time checkout and build of the sources,
       - repeated build, possibly after modifying something in the submodule.
     Currently bootstrap is optimized for the first one, and requires clumsy
     recipes for the second one. Such as:
       $ GNULIB_SRCDIR=`pwd`/gnulib ./autogen.sh --no-git

  2) A submodule has to be upgraded occasionally. bootstrap/autogen.sh does
     not help doing this. I have to keep a command in a cheat-sheet:
       $ (cd gnulib && git fetch && git merge origin/master); git add gnulib

  3) As can be seen in the recent thread, there is considerable disagreement
     regarding the handling of git submodules. Akim wants a fatal error when
     some git submodules have not been initialized, whereas Tim hates this.

I would propose to split the common bootstrap or autogen.sh into two
programs that can be invoked independently:

  1. A program that deals only with the git submodules.
  2. A program that only generates files (or, regarding PO files, fetches
     files that are not kept in git).

The developer should have the ability to set an environment variable
(GNULIB_SRCDIR or GNULIB_TOOL), to be used by both programs.

Advantages:
  - Developers can test modified gnulib sources without running through
    hoops.
  - Developers will have an easy way to upgrade to a newer gnulib version.
  - Different project policies regarding submodules are isolated in one place
    and thus have no influence on the gnulib-tool invocation, the PO file
    handling, etc.

Disadvantages:
  - The README-HACKING file will have to list two commands instead of one,
    for the first-time checkout.

What's your opinion?

I'd like to hear your voices, before I modify the autogen.sh scripts that
I maintain. I won't touch 'bootstrap' (not my domain).

Bruno

Re: bootstrap/autogen.sh and git submodules

[Gary V. Vaughan]

> On Mar 3, 2019, at 10:03 AM, Bruno Haible <bruno@clisp.org> wrote:
> 
> Hi,
> 
> When gnulib is used in a package, often the maintainers of that package
> use it via a git submodule, because that enables them to upgrade to newer
> versions of gnulib when they want to (and have a failsafe build between
> these upgrades), rather than having to adapt to gnulib changes at any moment.
> Even if it's only the imported file list which has changed, which might
> require an update to the package's .gitignore file.
> 
> The use of git submodules, however, has three problems:
> 
>  1) There are two use-cases of bootstrap/autogen.sh (the name does not matter):
>       - first-time checkout and build of the sources,
>       - repeated build, possibly after modifying something in the submodule.
>     Currently bootstrap is optimized for the first one, and requires clumsy
>     recipes for the second one. Such as:
>       $ GNULIB_SRCDIR=`pwd`/gnulib ./autogen.sh --no-git
> 
>  2) A submodule has to be upgraded occasionally. bootstrap/autogen.sh does
>     not help doing this. I have to keep a command in a cheat-sheet:
>       $ (cd gnulib && git fetch && git merge origin/master); git add gnulib
> 
>  3) As can be seen in the recent thread, there is considerable disagreement
>     regarding the handling of git submodules. Akim wants a fatal error when
>     some git submodules have not been initialized, whereas Tim hates this.
> 
> I would propose to split the common bootstrap or autogen.sh into two
> programs that can be invoked independently:
> 
>  1. A program that deals only with the git submodules.
>  2. A program that only generates files (or, regarding PO files, fetches
>     files that are not kept in git).
> 
> The developer should have the ability to set an environment variable
> (GNULIB_SRCDIR or GNULIB_TOOL), to be used by both programs.
> 
> Advantages:
>  - Developers can test modified gnulib sources without running through
>    hoops.
>  - Developers will have an easy way to upgrade to a newer gnulib version.
>  - Different project policies regarding submodules are isolated in one place
>    and thus have no influence on the gnulib-tool invocation, the PO file
>    handling, etc.
> 
> Disadvantages:
>  - The README-HACKING file will have to list two commands instead of one,
>    for the first-time checkout.
> 
> What's your opinion?
> 
> I'd like to hear your voices, before I modify the autogen.sh scripts that
> I maintain. I won't touch 'bootstrap' (not my domain).
> 
> Bruno

Hi Bruno,

It’s been so long since I maintained a gnulib client project that I feel barely qualified to offer an opinion here... I’m likely misunderstanding the question. I don’t even know what ./autogen.sh is for?

But answering as best I can purely for completeness’ sake, and assuming my memory is behaving well, I found using my bootstrap rewrite alone (usually with additional function overrides or wrappers in bootstrap.conf) to be entirely sufficient for:

1. running on a freshly cloned working copy to set everything up ready for ./configure && make

2. rebootstrapping after updating submodules

3. regenerating itself from an updated gnulib-modules/bootstrap submodule from time to time

Even so, after the Makefiles were configured, even editing autotools input files would not require rebootstrapping, so I really only needed to run bootstrap a few times per year per project when updated Automake on my laptop or gnulib submodule hashref in a working copy or similar. This is totally acceptable from my perspective, and doesn’t require any additional tooling or driver scripts.

Cheers,
Gary

Re: bootstrap/autogen.sh and git submodules

[Tim Rühsen]

[-- Attachment #1.1: Type: text/plain, Size: 2977 bytes --]

On 03.03.19 19:03, Bruno Haible wrote:
> Hi,
> 
> When gnulib is used in a package, often the maintainers of that package
> use it via a git submodule, because that enables them to upgrade to newer
> versions of gnulib when they want to (and have a failsafe build between
> these upgrades), rather than having to adapt to gnulib changes at any moment.
> Even if it's only the imported file list which has changed, which might
> require an update to the package's .gitignore file.
> 
> The use of git submodules, however, has three problems:
> 
>   1) There are two use-cases of bootstrap/autogen.sh (the name does not matter):
>        - first-time checkout and build of the sources,
>        - repeated build, possibly after modifying something in the submodule.
>      Currently bootstrap is optimized for the first one, and requires clumsy
>      recipes for the second one. Such as:
>        $ GNULIB_SRCDIR=`pwd`/gnulib ./autogen.sh --no-git
> 
>   2) A submodule has to be upgraded occasionally. bootstrap/autogen.sh does
>      not help doing this. I have to keep a command in a cheat-sheet:
>        $ (cd gnulib && git fetch && git merge origin/master); git add gnulib

You often see gnulib in a 'detached HEAD' state, so my variation is:
(cd gnulib && git checkout master && git pull): git commit -m "Update
gnulib" gnulib

>   3) As can be seen in the recent thread, there is considerable disagreement
>      regarding the handling of git submodules. Akim wants a fatal error when
>      some git submodules have not been initialized, whereas Tim hates this.

Not "hating" it, but it just fails ;-)
I was just searching for a way to disable the check... not sure what is
better suited, a cli option, an env variable or both.


> I would propose to split the common bootstrap or autogen.sh into two
> programs that can be invoked independently:
> 
>   1. A program that deals only with the git submodules.
>   2. A program that only generates files (or, regarding PO files, fetches
>      files that are not kept in git).
> 
> The developer should have the ability to set an environment variable
> (GNULIB_SRCDIR or GNULIB_TOOL), to be used by both programs.
> 
> Advantages:
>   - Developers can test modified gnulib sources without running through
>     hoops.
>   - Developers will have an easy way to upgrade to a newer gnulib version.
>   - Different project policies regarding submodules are isolated in one place
>     and thus have no influence on the gnulib-tool invocation, the PO file
>     handling, etc.
> 
> Disadvantages:
>   - The README-HACKING file will have to list two commands instead of one,
>     for the first-time checkout.
> 
> What's your opinion?

Make it so that existing build scripts don't have to be modified. E.g.
splitting bootstrap/autogen.sh into two commands is ok as long as the
original command invokes both (and thus being backwards compatible).

Regards, Tim


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: bootstrap/autogen.sh and git submodules

[Bruno Haible]

Hi Gary,

> ... entirely sufficient for:
> 
> 1. running on a freshly cloned working copy to set everything up ready for ./configure && make
> 
> 2. rebootstrapping after updating submodules

Yes, it is sufficient for the "simple" cases.

What the current bootstrap is not good at:

  * Keeping the developer in control of git. When I am a developer, I may
    want to control precisely which version of the submodule I want to
    use. For example, if I am about to make a release, I may want to
    pull some but not all recent commits from the submodule. Or I may want
    to try changes that are not yet committed.

    As the maintainer of a package I may want to run all git commands by
    myself (and remember what I've done), rather than have some script do it
    for me.

  * Hiding the 'git submodule' complexity from the developer. Everyone
    is familiar with the basic commands of git. But 'git submodule' is a
    different set of commands with a different philosophy. And its own
    set of pitfalls [1].

You may say that these two goals are incompatible. I disagree.

  - To fulfil the first goal, it is sufficient to move all git operations
    to a separate script.
  - To fulfil the second goal is an art. But just like 'gnupload' allows me
    to forget how to invoke 'gpg', why would that separate script now allow
    to forget me how to invoke 'git submodule'?

Bruno

[1] https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/

Re: bootstrap/autogen.sh and git submodules

[Bernhard Voelker]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On 3/3/19 7:03 PM, Bruno Haible wrote:
>   2) A submodule has to be upgraded occasionally. bootstrap/autogen.sh does
>      not help doing this. I have to keep a command in a cheat-sheet:
>        $ (cd gnulib && git fetch && git merge origin/master); git add gnulib

Additionally to updating gnulib, often some projects need to sync additional
files from the freshly updated gnulib subdirectory, like e.g. bootstrap or COPYING.

In December, I've suggested [1] the new makefile target 'update-gnulib-to-lates'
(alias 'gnulib-sync') which allows to specify a hook to perform such additional
tasks - see attached.

In coreutils, the hook for copying the extra files boils down to (in cfg.mk):

+# Override gnulib to copy some files from there during 'make gnulib-sync'.
+cu_GNULIB_SYNC_HOOK:
+	@{ cd $(srcdir) \
+	    && set -x \
+	    && cp gnulib/doc/COPYINGv3 COPYING \
+	    && cp gnulib/build-aux/bootstrap bootstrap \
+	    && cp gnulib/tests/init.sh tests/init.sh \
+	; }
+export _gl_GNULIB_SYNC_HOOK = cu_GNULIB_SYNC_HOOK

[1] http://lists.gnu.org/archive/html/coreutils/2018-12/msg00007.html

WDYT?

Have a nice day,
Berny

[-- Attachment #2: 0001-maintainer-makefile-provide-make-target-to-update-gn.patch --]
[-- Type: text/x-patch, Size: 3293 bytes --]

From 5a07e65cd38fa949294e384fd5635408df4f2fab Mon Sep 17 00:00:00 2001
From: Bernhard Voelker <mail@bernhard-voelker.de>
Date: Thu, 13 Dec 2018 00:35:23 +0100
Subject: [PATCH] maintainer-makefile: provide make target to update gnulib to
 latest

* top/maint.mk (gnulib-sync, update-gnulib-to-latest): Add targets,
using the following hook variable to optionally e.g copy some files
from gnulib into the own package after pulling.
(_gl_GNULIB_SYNC_HOOK): Add hook variable to be
optionally overridden in 'cfg.mk'.  Default to ...
(_gl_GNULIB_SYNC_HOOK_empty): ... this empty target.
---
 ChangeLog    | 10 ++++++++++
 top/maint.mk | 36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index e3c929b52..313eb2a83 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2018-10-28  Bernhard Voelker  <mail@bernhard-voelker.de>
+
+	maintainer-makefile: provide make target to update gnulib to latest
+	* top/maint.mk (gnulib-sync, update-gnulib-to-latest): Add targets,
+	using the following hook variable to optionally e.g copy some files
+	from gnulib into the own package after pulling.
+	(_gl_GNULIB_SYNC_HOOK): Add hook variable to be
+	optionally overridden in 'cfg.mk'.  Default to ...
+	(_gl_GNULIB_SYNC_HOOK_empty): ... this empty target.
+
 2018-12-13  Bruno Haible  <bruno@clisp.org>
 
 	select tests: Avoid test failure on Cygwin.
diff --git a/top/maint.mk b/top/maint.mk
index 4889ebacc..b90a776dc 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1571,6 +1571,42 @@ update-copyright:
 	  $$(export VC_LIST_EXCEPT_DEFAULT=COPYING && $(VC_LIST_EXCEPT)) \
 	  | $(update-copyright-env) xargs $(srcdir)/$(_build-aux)/$@
 
+# 'gnulib-sync': Update gnulib to latest.
+# Prerequisite: the working tree of both your package and gnulib are clean
+# (which is checked first).
+# To optionally copy some additional files from there right after the pull,
+# override the '_gl_GNULIB_SYNC_HOOK' make variable in your 'cfg.mk' with
+# the name of the make target which is then actually taking over the files.
+# This can be useful for files you need to have physically in your repository,
+# like e.g. 'COPYING' (for legal reasons) or 'bootstrap'.
+# Example:
+#   my_GNULIB_SYNC_HOOK:
+#   	@{ cd $(srcdir) \
+#   	    && cp gnulib/doc/COPYINGv3 COPYING \
+#   	    && cp gnulib/build-aux/bootstrap bootstrap \
+#   	; }
+#   export _gl_GNULIB_SYNC_HOOK = my_GNULIB_SYNC_HOOK
+#
+# Declare the default hook target (empty).
+.PHONY: _gl_GNULIB_SYNC_HOOK_empty
+_gl_GNULIB_SYNC_HOOK ?= _gl_GNULIB_SYNC_HOOK_empty
+_gl_GNULIB_SYNC_HOOK_empty:
+
+.PHONY: gnulib-sync update-gnulib-to-latest
+gnulib-sync update-gnulib-to-latest:
+	@{ cd $(srcdir) \
+	    && { printf 'gnulib: ' && git -C gnulib describe --always --dirty \
+		  && printf 'your package: ' && git describe --always --dirty \
+		  || echo dirty; \
+		  } | grep 'dirty$$' \
+			&& { echo "$@: error: tree is dirty" >&2; exit 1; } \
+			|| : \
+	    && set -x \
+	    && git -C gnulib pull origin master \
+	    && $(MAKE) $(_gl_GNULIB_SYNC_HOOK) \
+	    && git status --short --untracked-files=no \
+	; }
+
 # This tight_scope test is skipped with a warning if $(_gl_TS_headers) is not
 # overridden and $(_gl_TS_dir)/Makefile.am does not mention noinst_HEADERS.
 
-- 
2.19.2

Re: bootstrap/autogen.sh and git submodules

[Bruno Haible]

Hi,

On 2019-03-03 I listed the problems that I have with the existing practices
of using gnulib as a submodule.

Here's my attempt to fix this for the packages I maintain (gettext,
libunistring, etc.). It's a new script 'gitsub.sh'.

The main point is a clear separation between git / version control
related stuff (all in gitsub.sh) and regeneration of files (all in autogen.sh).

Tim Rühsen wrote:
> Make it so that existing build scripts don't have to be modified. E.g.
> splitting bootstrap/autogen.sh into two commands is ok as long as the
> original command invokes both (and thus being backwards compatible).

I disagree, this is not realizable. But to care about this situation,
I modify autogen.sh so that it exits with an error message
  *** Subdirectory 'gnulib' does not yet exist. Use './gitsub.sh pull' to create it, or set the environment variable GNULIB_SRCDIR.
when necessary.

Here's the rewritten text from HACKING:
===============================================================================

Building off the Git repository
===============================

Access to the Git repository is described at
https://savannah.gnu.org/git/?group=gettext .

After fetching the sources from the Git repository, peek at the comments in
autogen.sh, then run
  ./gitsub.sh pull
  ./autogen.sh
Then you can proceed with "./configure" as usual.

Each time you want to update the source, do not only "git pull".  Instead do
  git pull && ./gitsub.sh pull
  ./autogen.sh
===============================================================================

Here's the proposed gitsub.sh script (to be shared through gnulib,
outside of any module, like 'bootstrap'):
================================== gitsub.sh ==================================
#! /bin/sh
#
# Copyright (C) 2019 Free Software Foundation, Inc.
# Written by Bruno Haible <bruno@clisp.org>, 2019.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.

# Program that manages the subdirectories of a git checkout of a package
# that come from other packages (called "dependency packages").
#
# This program is similar in spirit to 'git submodule', with three
# essential differences:
#
#   1) Its options are easy to remember, and do not require knowledge of
#      'git submodule'.
#
#   2) The developer may choose to work on a different checkout for each
#      dependency package.  This is important when the developer is
#      preparing simultaneous changes to the package and the dependency
#      package, or is using the dependency package in several packages.
#
#      The developer indicates this different checkout by setting the
#      environment variable <SUBDIR>_SRCDIR (e.g. GNULIB_SRCDIR) to point to it.
#
#   3) The package maintainer may choose to use or not use git submodules.
#
#      The advantages of management through a git submodule are:
#        - Changes to the dependency package cannot suddenly break your package.
#          In other words, when there is an incompatible change that will cause
#          a breakage, you can fix things at your pace; you are not forced to
#          cope with such breakages in an emergency.
#        - When you need to make a change as a response to a change in the
#          dependency package, your co-developers cannot accidentally mix things
#          up (for example, use a combination of your newest change with an
#          older version of the dependency package).
#
#      The advantages of management without a git submodule (just as a plain
#      subdirectory, let's call it a "subcheckout") are:
#        - The simplicity: you are conceptually always using the newest revision
#          of the dependency package.
#        - You don't have to remember to periodially upgrade the dependency.
#          Upgrading the dependency is an implicit operation.

# This program is meant to be copied to the top-level directory of the package,
# together with a configuration file.  The configuration is supposed to be
# named '.gitmodules' and to define:
# * The git submodules, as described in "man 5 gitmodules" or
#   <https://git-scm.com/docs/gitmodules>.  For example:
#
#       [submodule "gnulib"]
#               url = git://git.savannah.gnu.org/gnulib.git
#               path = gnulib
#
#   You don't add this piece of configuration to .gitmodules manually.  Instead,
#   you would invoke
#     $ git submodule add --name "gnulib" -- git://git.savannah.gnu.org/gnulib.git gnulib
#
# * The subdirectories that are not git submodules, in a similar syntax.  For
#   example:
#
#       [subcheckout "gnulib"]
#               url = git://git.savannah.gnu.org/gnulib.git
#               path = gnulib
#
# Here the URL is the one used for anonymous checkouts of the dependency
# package. If the developer needs a checkout with write access, they can
# either set the GNULIB_SRCDIR environment variable to point to that checkout
# or modify the gnulib/.git/config file to enter a different URL.

scriptname="$0"
scriptversion='2019-04-01'
nl='
'
IFS=" ""	$nl"

# func_usage
# outputs to stdout the --help usage message.
func_usage ()
{
  echo "\
Usage: gitsub.sh pull [SUBDIR]
       gitsub.sh upgrade [SUBDIR]
       gitsub.sh checkout SUBDIR REVISION

Operations:

gitsub.sh pull [SUBDIR]
        You should perform this operation after 'git clone ...' and after
        every 'git pull'.
        It brings your checkout in sync with what the other developers of
        your package have committed and pushed.
        If an environment variable <SUBDIR>_SRCDIR is set, with a non-empty
        value, nothing is done for this SUBDIR.
        If no SUBDIR is specified, the operation applies to all dependencies.

gitsub.sh upgrade [SUBDIR]
        You should perform this operation periodically, to ensure currency
        of the dependency package revisions that you use.
        This operation pulls and checks out the changes that the developers
        of the dependency package have committed and pushed.
        If an environment variable <SUBDIR>_SRCDIR is set, with a non-empty
        value, nothing is done for this SUBDIR.
        If no SUBDIR is specified, the operation applies to all dependencies.

gitsub.sh checkout SUBDIR REVISION
        Checks out a specific revision for a dependency package.
        If an environment variable <SUBDIR>_SRCDIR is set, with a non-empty
        value, this operation fails.

This script requires the git program in the PATH and an internet connection.
"
}

# func_version
# outputs to stdout the --version message.
func_version ()
{
  year=`echo "$scriptversion" | sed -e 's/^\(....\)-.*/\1/'`
  echo "\
gitsub.sh (GNU gnulib) $scriptversion
Copyright (C) 2019-$year Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
"
  printf "Written by %s.\n" "Bruno Haible"
}

# func_fatal_error message
# outputs to stderr a fatal error message, and terminates the program.
# Input:
# - scriptname               name of this program
func_fatal_error ()
{
  echo "$scriptname: *** $1" 1>&2
  echo "$scriptname: *** Stop." 1>&2
  exit 1
}

# func_warning message
# Outputs to stderr a warning message,
func_warning ()
{
  echo "gitsub.sh: warning: $1" 1>&2
}

# func_note message
# Outputs to stdout a note message,
func_note ()
{
  echo "gitsub.sh: note: $1"
}

# Unset CDPATH.  Otherwise, output from 'cd dir' can surprise callers.
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH

# Command-line option processing.
mode=
while test $# -gt 0; do
  case "$1" in
    --help | --hel | --he | --h )
      func_usage
      exit $? ;;
    --version | --versio | --versi | --vers | --ver | --ve | --v )
      func_version
      exit $? ;;
    -- )
      # Stop option processing
      shift
      break ;;
    -* )
      echo "gitsub.sh: unknown option $1" 1>&2
      echo "Try 'gitsub.sh --help' for more information." 1>&2
      exit 1 ;;
    * )
      break ;;
  esac
done
if test $# = 0; then
  echo "gitsub.sh: missing operation argument" 1>&2
  echo "Try 'gitsub.sh --help' for more information." 1>&2
  exit 1
fi
case "$1" in
  pull | upgrade | checkout )
    mode="$1"
    shift ;;
  *)
    echo "gitsub.sh: unknown operation '$1'" 1>&2
    echo "Try 'gitsub.sh --help' for more information." 1>&2
    exit 1 ;;
esac
if test $# = 2 && test $mode != checkout || test $# -gt 2; then
  echo "gitsub.sh: too many arguments in '$mode' mode" 1>&2
  echo "Try 'gitsub.sh --help' for more information." 1>&2
  exit 1
fi
if test $# = 0 && test $mode = checkout; then
  echo "gitsub.sh: too few arguments in '$mode' mode" 1>&2
  echo "Try 'gitsub.sh --help' for more information." 1>&2
  exit 1
fi

# Read the configuration.
# Output:
# - subcheckouts             space-separated list of subcheckout names
# - submodules               space-separated list of submodule names
if test -f .gitmodules; then
  subcheckouts=`git config --file .gitmodules --get-regexp --name-only 'subcheckout\..*\.url' | sed -e 's/^subcheckout\.//' -e 's/\.url$//' | tr -d '\r' | tr '\n' ' '`
  submodules=`git config --file .gitmodules --get-regexp --name-only 'submodule\..*\.url' | sed -e 's/^submodule\.//' -e 's/\.url$//' | tr -d '\r' | tr '\n' ' '`
else
  subcheckouts=
  submodules=
fi

# func_validate SUBDIR
# Verifies that the state on the file system is in sync with the declarations
# in the configuration file.
# Input:
# - subcheckouts             space-separated list of subcheckout names
# - submodules               space-separated list of submodule names
# Output:
# - srcdirvar                Environment that the user can set
# - srcdir                   Value of the environment variable
# - path                     if $srcdir != "": relative path of the subdirectory
# - url                      if $srcdir != "" and $path is not a directory:
#                            the repository URL
func_validate ()
{
  srcdirvar=`echo "$1" | LC_ALL=C sed -e 's/[^a-zA-Z0-9]/_/g' | LC_ALL=C tr '[a-z]' '[A-Z]'`"_SRCDIR"
  eval 'srcdir=$'"$srcdirvar"
  path=
  url=
  if test -n "$srcdir"; then
    func_note "Ignoring '$1' because $srcdirvar is set."
  else
    found=false
    case " $subcheckouts " in *" $1 "*)
      found=true
      # It ought to be a subcheckout.
      path=`git config --file .gitmodules "subcheckout.$1.path"`
      if test -z "$path"; then
        path="$1"
      fi
      if test -d "$path"; then
        if test -d "$path/.git"; then
          # It's a plain checkout.
          :
        else
          if test -f "$path/.git"; then
            # It's a submodule.
            func_fatal_error "Subdirectory '$path' is supposed to be a plain checkout, but it is a submodule."
          else
            func_warning "Ignoring '$path' because it exists but is not a git checkout."
          fi
        fi
      else
        # The subdir does not yet exist.
        url=`git config --file .gitmodules "subcheckout.$1.url"`
        if test -z "$url"; then
          func_fatal_error "Property subcheckout.$1.url is not defined in .gitmodules"
        fi
      fi
      ;;
    esac
    case " $submodules " in *" $1 "*)
      found=true
      # It ought to be a submodule.
      path=`git config --file .gitmodules "submodule.$1.path"`
      if test -z "$path"; then
        path="$1"
      fi
      if test -d "$path"; then
        if test -d "$path/.git"; then
          # It's a plain checkout.
          func_fatal_error "Subdirectory '$path' is supposed to be a submodule, but it is a plain checkout."
        else
          if test -f "$path/.git"; then
            # It's a submodule.
            :
          else
            func_warning "Ignoring '$path' because it exists but is not a git checkout."
          fi
        fi
      else
        # The subdir does not yet exist.
        url=`git config --file .gitmodules "submodule.$1.url"`
        if test -z "$url"; then
          func_fatal_error "Property submodule.$1.url is not defined in .gitmodules"
        fi
      fi
      ;;
    esac
    if ! $found; then
      func_fatal_error "Subdir '$1' is not configured as a subcheckout or a submodule in .gitmodules"
    fi
  fi
}

# func_cleanup_current_git_clone
# Cleans up the current 'git clone' operation.
# Input:
# - path
func_cleanup_current_git_clone ()
{
  rm -rf "$path"
  func_fatal_error "git clone failed"
}

# func_pull SUBDIR
# Implements the 'pull' operation.
func_pull ()
{
  func_validate "$1"
  if test -z "$srcdir"; then
    case " $subcheckouts " in *" $1 "*)
      # It's a subcheckout.
      if test -d "$path"; then
        if test -d "$path/.git"; then
          (cd "$path" && git pull) || func_fatal_error "git operation failed"
        fi
      else
        # The subdir does not yet exist. Create a plain checkout.
        trap func_cleanup_current_git_clone 1 2 13 15
        git clone "$url" "$path" || func_cleanup_current_git_clone
        trap - 1 2 13 15
      fi
      ;;
    esac
    case " $submodules " in *" $1 "*)
      # It's a submodule.
      if test -d "$path"; then
        if test -f "$path/.git"; then
          # See https://stackoverflow.com/questions/1030169/easy-way-to-pull-latest-of-all-git-submodules
          # https://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules
          git submodule update "$path" || func_fatal_error "git operation failed"
        fi
      else
        # The subdir does not yet exist. Create a submodule checkout.
        git submodule init -- "$path" && git submodule update -- "$path" || func_fatal_error "git operation failed"
      fi
      ;;
    esac
  fi
}

# func_upgrade SUBDIR
# Implements the 'upgrade' operation.
func_upgrade ()
{
  func_validate "$1"
  if test -z "$srcdir"; then
    if test -d "$path"; then
      case " $subcheckouts " in *" $1 "*)
        # It's a subcheckout.
        if test -d "$path/.git"; then
          (cd "$path" && git pull) || func_fatal_error "git operation failed"
        fi
        ;;
      esac
      case " $submodules " in *" $1 "*)
        # It's a submodule.
        if test -f "$path/.git"; then
          (cd "$path" && git fetch && git merge origin/master) || func_fatal_error "git operation failed"
        fi
        ;;
      esac
    else
      # The subdir does not yet exist.
      func_fatal_error "Subdirectory '$path' does not exist yet. Use 'gitsub.sh pull' to create it."
    fi
  fi
}

# func_checkout SUBDIR REVISION
# Implements the 'checkout' operation.
func_checkout ()
{
  func_validate "$1"
  if test -z "$srcdir"; then
    if test -d "$path"; then
      case " $subcheckouts " in *" $1 "*)
        # It's a subcheckout.
        if test -d "$path/.git"; then
          (cd "$path" && git checkout "$2") || func_fatal_error "git operation failed"
        fi
        ;;
      esac
      case " $submodules " in *" $1 "*)
        # It's a submodule.
        if test -f "$path/.git"; then
          (cd "$path" && git checkout "$2") || func_fatal_error "git operation failed"
        fi
        ;;
      esac
    else
      # The subdir does not yet exist.
      func_fatal_error "Subdirectory '$path' does not exist yet. Use 'gitsub.sh pull' to create it."
    fi
  fi
}

case "$mode" in
  pull )
    if test $# = 0; then
      for subdir in $subcheckouts $submodules; do
        func_pull "$subdir"
      done
    else
      valid=false
      for subdir in $subcheckouts $submodules; do
        if test "$subdir" = "$1"; then
          valid=true
        fi
      done
      if $valid; then
        func_pull "$1"
      else
        func_fatal_error "Subdir '$1' is not configured as a subcheckout or a submodule in .gitmodules"
      fi
    fi
    ;;

  upgrade )
    if test $# = 0; then
      for subdir in $subcheckouts $submodules; do
        func_upgrade "$subdir"
      done
    else
      valid=false
      for subdir in $subcheckouts $submodules; do
        if test "$subdir" = "$1"; then
          valid=true
        fi
      done
      if $valid; then
        func_upgrade "$1"
      else
        func_fatal_error "Subdir '$1' is not configured as a subcheckout or a submodule in .gitmodules"
      fi
    fi
    ;;

  checkout )
    valid=false
    for subdir in $subcheckouts $submodules; do
      if test "$subdir" = "$1"; then
        valid=true
      fi
    done
    if $valid; then
      func_checkout "$1" "$2"
    else
      func_fatal_error "Subdir '$1' is not configured as a subcheckout or a submodule in .gitmodules"
    fi
    ;;
esac
===============================================================================

Note: This script is not related nor derived from
https://github.com/feluxe/gitsub .

Comments welcome!

Bruno

Re: bootstrap/autogen.sh and git submodules

[Bruno Haible]

Bernhard Voelker wrote:
> Additionally to updating gnulib, often some projects need to sync additional
> files from the freshly updated gnulib subdirectory, like e.g. bootstrap or COPYING.
> ...
> WDYT?

Copying files is one thing; that can be done wherever in your build system
(autogen.sh, bootstrap, Makefiles), without causing headaches.

Doing a 'git pull origin master' from within a Makefile is more hairy. It's OK
when none of your co-developer contributes back to gnulib. But when you start
to want to make modifications to gnulib and test them using your package, such
a mix between version-control stuff and build-related stuff causes major
headaches.

I know it's tempting: I have such an 'update-gnulib' rule in a Makefile in
GNU clisp myself, because it's handy...

Bruno

Re: bootstrap/autogen.sh and git submodules

[Daiki Ueno]

Hello Bruno,

Bruno Haible <bruno@clisp.org> writes:

> On 2019-03-03 I listed the problems that I have with the existing practices
> of using gnulib as a submodule.
>
> Here's my attempt to fix this for the packages I maintain (gettext,
> libunistring, etc.). It's a new script 'gitsub.sh'.

I should have commented earlier, but I wanted to express my motivation
behind the switch to using "git submodule" in gettext.  That was not for
making upgrades easier, but for making change tracking easier.

Prior to the switch, I could only see the "Update after gnulib changed."
messages in the "git log" output, without any mention of the target
revisions of gnulib.  That was making "git bisect" hard.

With "git submodule", those gnulib revisions are automatically recorded
and I can easily move back to a specific revision of the gettext, which
is somehow guaranteed to compile.

Therefore, if the new script provides a similar feature, without adding
a manual process to our current practice, I wouldn't oppose.  Otherwise
it seems like a bit of a step back to me.

Regards,
-- 
Daiki Ueno

Re: bootstrap/autogen.sh and git submodules

[Bruno Haible]

Hello Daiki,

> I wanted to express my motivation
> behind the switch to using "git submodule" in gettext.  That was not for
> making upgrades easier, but for making change tracking easier.
> ... That was making "git bisect" hard.

I'm not turning off git submodules in gettext. I'm also not suggesting
not to use git submodules. Git submodules have their advantages - as well
as their disadvantages. It's a trade-off.

The gitsub.sh script supports projects with submodules as well as projects
with no submodules (plain checkouts) in the *same* way. So that you don't
have to remember different commands when working in gettext and in
libunistring. Previously I had to remember that in some projects I have
to do
  git pull; (cd gnulib && git pull)
and in other projects
  git pull; git submodule update --recursive

The gitsub.sh script's purpose is also to put control of git status
back into the developer's hands. When there is an autogen.sh script or
'bootstrap' script or Makefile rules that moves the git checkout to a
different commit than the one that I had picked, it makes it very
hard to just *build* locally modified source code. Previously I had to
do something like
  GNULIB_SRCDIR=`pwd`/gnulib ./autogen.sh --no-git
which is an insanely complex way to achieve something that should be
easy by default.

I have just pushed a copy of gitsub.sh to gettext. Let me know if you have
usability problems with it (after having read the updated HACKING file).

Bruno

Re: bootstrap/autogen.sh and git submodules

[Bruno Haible]

On 2019-04-01 I wrote:
> Here's the proposed gitsub.sh script (to be shared through gnulib,
> outside of any module, like 'bootstrap'):
> ================================== gitsub.sh ==================================

After I made a couple of corrections to this script on 2019-04-02, I am
using it for several weeks in several projects, and it fixes all the
qualms I had with the previous approach that took version control out
of my hands.

So I'm committing it.


2019-04-02  Bruno Haible  <bruno@clisp.org>

	gitsub.sh: New file.
	* top/gitsub.sh: New file.