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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.