Re: [RFC/PATCH] add update to branch support for "floating submodules"

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Dec 10, 2011, 06:19 UTC
Message-ID: <20111210061906.GA11326@elie.hsd1.il.comcast.net>
In-Reply-To: <loom.20111210T062013-538@post.gmane.org>

(restoring cc list) Hi Leif,

Leif Gruenwoldt wrote:

Show 5 quoted lines

> 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