bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib and version control


From: Bruno Haible
Subject: Re: gnulib and version control
Date: Fri, 26 Aug 2022 12:59:35 +0200

In [1] we document three approaches, dependending on the package's usual
handling of imported/generated files.

Dima Pasechnik wrote:
> If a project does not use git's submodules, noone wants an extra
> complexity of submodules to be added to the build system just due to
> the need for gnulib.

Sure. No one forces you to use a git submodule. As written in [1]:
  "The alternative is to always follow the newest Gnulib automatically.
   Note that this can cause breakages at unexpected moments, namely when
   a broken commit is pushed in Gnulib. It does not happen often, but it
   does happen."

> In some projects I am or was involved, it's basically the case that the code 
> injected by
> the gnulib-tool got committed into the tree, and blissfully forgotten
> about. 

Yes, that's one possibility.

> Why you at gnulib headquarters want large chunks of gnulib
> scattered accross many, many thousands of downstream git trees, I don't know.

This is not what we "want". The documentation [1] gives three options. You
choose the one that fits best for your package.

> My point is that it's used "elsewhere" not in the way you envision, but
> by simply committing the code produced by gnulib-tool into the source
> tree, and forgetting all about it.

You must have studied the various packages that use gnulib quite extensively,
but I have done that too. My impression is that the vast majority follows the
principle "don't commit generated files into version control", that is, they
use approach 2, not approach 1, from [1].

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html






reply via email to

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