bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

maint.mk: public-submodule-commit rule is broken


From: Bruno Haible
Subject: maint.mk: public-submodule-commit rule is broken
Date: Sun, 11 Sep 2022 18:44:47 +0200

Hi Jim,

In GNU gettext, I'm now using one of the 'stable-*' branches of gnulib.

And maint.mk gives me an error:

$ make check
if test -d ./.git                               \
        && git --version >/dev/null 2>&1; then                  \
  cd . &&                                               \
  git submodule --quiet foreach                                 \
      'test "$(git rev-parse "$sha1")"                  \
          = "$(git merge-base origin "$sha1")"'         \
    || { echo 'maint.mk: found non-public submodule commit' >&2;        \
         exit 1; };                                             \
else                                                            \
  : ;                                                           \
fi
fatal: run_command returned non-zero status for gnulib
.
maint.mk: found non-public submodule commit
make: *** [maint.mk:1489: public-submodule-commit] Error 1


Two things are wrong here:

1) I should not be getting a "found non-public submodule commit" error,
since the gnulib commit that I am using *is* public. See:

$ git submodule foreach 'echo $sha1; test "$(git rev-parse "$sha1")" = "$(git 
merge-base origin "$sha1")"'
Entering 'gnulib'
dc631883e47212d5cd311575b491cb5b093b34d9
fatal: run_command returned non-zero status for gnulib
.
$ git rev-parse dc631883e47212d5cd311575b491cb5b093b34d9
dc631883e47212d5cd311575b491cb5b093b34d9
$ git merge-base origin dc631883e47212d5cd311575b491cb5b093b34d9
fatal: Not a valid commit name dc631883e47212d5cd311575b491cb5b093b34d9

So,
  git merge-base origin "$sha1"
fails. But that does not mean that the commit is non-public. You can see
the commit at
  
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=dc631883e47212d5cd311575b491cb5b093b34d9

2) The 'public-submodule-commit' is not suitable for hooking into
"make check". It would be better hooked into "make distcheck".

Why? Because as a developer who has write access to a submodule the normal
workflow is like this:
  1. Check out a public master or branch of the submodule.
  2. Prepare a change to the submodule. Commit it but don't push it.
  3. In the parent package, do "make" and "make check", to verify that it
     doesn't cause a regression.
  4. Push the change in the submodule.

If you hook 'public-submodule-commit' into "make check", you are forcing
the developer to swap steps 3 and 4. That is, to push a change to the public,
before having verified that it does not cause regressions!


Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]