From: Jens Lehmann <Jens.Lehmann@web.de>
To: Phil Hord <phil.hord@gmail.com>
Cc: "Andreas T.Auer" <andreas.t.auer_gtml_37453@ursus.ath.cx>,
git@vger.kernel.org
Subject: Re: Auto update submodules after merge and reset
Date: Tue, 13 Dec 2011 08:52:07 +0100 [thread overview]
Message-ID: <4EE70427.3010605@web.de> (raw)
In-Reply-To: <CABURp0r37+VHBVVKepHPC4jwa-wJ0b+qwLrhhFR8KXnMQYTT3w@mail.gmail.com>
Am 13.12.2011 00:43, schrieb Phil Hord:
> On Mon, Dec 12, 2011 at 5:39 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 11.12.2011 22:15, schrieb Andreas T.Auer:
>>> In http://thread.gmane.org/gmane.comp.version-control.git/183837 was discussed whether the gitlink in the superproject should be set to all-zero if updates follow the tip or maybe use the SHA1 of the commit when the submodule was added. I think the gitlink should be updated everytime when a new commit in the superproject is created.
>>
>> Nope, only when "git submodule update" is run. Otherwise you'll spray the
>> history with submodule updates totally unrelated to the commits in the
>> superproject, which is rather confusing.
>
> And this is why my superproject is a makefile, a .gitmodules file and
> a bunch of gitlinks. We only use it to track the advancement of
> submodule activity.
Which is fine. Did you think about having a branch where only the
submodules are updated (and built and tested) and committed to by a
buildbot when everything is fine? You could then merge that branch
whenever you want up-to-date submodules and have the reproducibility
of the exact model while being able to "float" along the updates of
that branch?
I think it always boils down to this: Either commit new gitlinks, so
the submodules get updated in a reproducible manner, or don't use
gitlinks at all so the submodules can float wherever they want.
> So yes, I want my superproject's gitlinks to update automatically. I
> just don't know a smart way to make that happen.
Yup, that has been the endpoint of all discussions about that topic
so far. And until someone comes up with a smart way to make that
happen, I would rather not put something half-baked into git.
(But please tell us when you found a smart way to do that! ;-)
next prev parent reply other threads:[~2011-12-13 7:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-30 0:55 Auto update submodules after merge and reset Max Krasnyansky
2011-11-30 8:31 ` Jens Lehmann
2011-12-06 1:06 ` Max Krasnyansky
2011-12-06 21:32 ` Jens Lehmann
2011-12-07 9:07 ` Andreas T.Auer
2011-12-07 22:23 ` Jens Lehmann
2011-12-08 9:13 ` andreas.t.auer_gtml_37453
2011-12-09 23:57 ` Phil Hord
2011-12-10 1:41 ` Andreas T.Auer
2011-12-11 14:43 ` Phil Hord
2011-12-11 21:15 ` Andreas T.Auer
2011-12-12 22:39 ` Jens Lehmann
2011-12-12 23:43 ` Phil Hord
2011-12-13 7:52 ` Jens Lehmann [this message]
2011-12-13 9:45 ` Andreas T.Auer
2011-12-13 21:44 ` Jens Lehmann
2011-12-13 23:05 ` Andreas T.Auer
2011-12-14 15:16 ` Marc Branchaud
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE70427.3010605@web.de \
--to=jens.lehmann@web.de \
--cc=andreas.t.auer_gtml_37453@ursus.ath.cx \
--cc=git@vger.kernel.org \
--cc=phil.hord@gmail.com \
/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 NNTP newsgroup(s).