(restoring cc list)
Hi Leif,
Leif Gruenwoldt wrote:
> If I understand the description of "floating submodules", it's something I have
> been wanting for a while now! The lack of it is currently a deal breaker for
> using submodules within my organisation.
>
> Our use case is as follows.
[...]
> When one of the products is in
> heavy development we often need to do a lot of work in the common repos. Having
> to increment the sha1 of the submodules to track the latest tip would be overly
> arduous.
What happens when a bug was introduced in this period of heavy development
and someone wants to look back in the development history and build each
version to find which introduced the bug?
If I were part of such a project, I would be tempted to follow one of two
rules. Either
A. Each commit of productA strives to work with the latest version of
the common code possible. Which version of the common code that was
tested against gets recorded (perhaps by some record-submodule-versions-
and-commit script, or even a pre-commit hook) so others can
reproduce the results.
or
B. Occasionally (e.g., daily or weekly) the "baseline" version of the
common code that can be relied on gets bumped, and each commit of
productA should work with that version and all later versions for a
while. Everyday development might typically happen with the tip
version of the common code which may be faster, have more
bugfixes, and otherwise be more pleasant to work with, but commits
should work against the baseline version as well. When it is time
to bump the baseline, that fact gets recorded (in a separate
commit).
For this, the '[submodule "<name>"] ignore' setting described in
gitmodules(5) might be helpful.
Though of course other variations are possible.
Would you be able to try out using Heiko's patch for a while, adapt it
to your needs as necessary, and let us know how it goes?
Thanks very much, and good luck,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html