[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib via submodule
From: |
John Darrington |
Subject: |
Re: gnulib via submodule |
Date: |
Fri, 4 Sep 2020 08:45:29 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Thu, Sep 03, 2020 at 06:02:13PM -0300, Michel Boaventura wrote:
I really like the idea. I've worked on a lot of opensource projects and
most of
them use git submodules.
So have I. But personally I don't like this feature of git.
I continually find that I inadvertently reset the submodule to the wrong
commit. This is partly due to my habit of commiting using "git commit -a".
And when the submodule needs to be updated in people's local repositories it is
also not simple for them to do so.
On 20/09/03 01:01PM, Ben Pfaff wrote:
> Git has a feature called a "submodule" that allows one to add a specific
> commit of a repository in a subdirectory. This might be a better way for
> PSPP to integrate with gnulib, since PSPP demands a specific commit
> of gnulib. Git would then take over some of the work that developers and
> builders have to do manually (reading README.Git to find out the
> correct commit).
We've been using the README.Git method for a long time now. Existing
developers
do not have any problems with it so far as I'm aware. As for "builders", if
they choose to build directly from Git, I think issue is the least of their
worries. They will also have a lot more thinks to install - many of which must
be at particular versions - such as automake, autoconf, gperf, gimp, texinfo,
etc.
It is indeed awkward - that is why the recommended way is to build from a
tarball.
One thing that perhaps we could consider is arranging for an error/warning if
the
gnulib head does not match that mentioned in README.Git
J'