From: Bruno Haible <bruno@clisp.org>
To: "Gary V. Vaughan" <gary@vaughan.pe>
Cc: bug-gnulib@gnu.org
Subject: Re: bootstrap/autogen.sh and git submodules
Date: Sun, 03 Mar 2019 22:50:40 +0100 [thread overview]
Message-ID: <2497947.KseB9fE10F@omega> (raw)
In-Reply-To: <45A2F6BD-DDBD-4753-9076-E55CA012095D@vaughan.pe>
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/
next prev parent reply other threads:[~2019-03-03 21:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-03 18:03 bootstrap/autogen.sh and git submodules Bruno Haible
2019-03-03 19:01 ` Gary V. Vaughan
2019-03-03 21:50 ` Bruno Haible [this message]
2019-03-03 20:13 ` Tim Rühsen
2019-03-04 7:42 ` Bernhard Voelker
2019-04-01 15:54 ` Bruno Haible
2019-04-01 15:39 ` Bruno Haible
2019-04-02 16:36 ` Daiki Ueno
2019-04-02 17:55 ` Bruno Haible
2019-04-26 22:57 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2497947.KseB9fE10F@omega \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=gary@vaughan.pe \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).