From: Junio C Hamano <hidden> Date: 2016-06-15 22:52:27
Heiko Voigt [off-list ref] writes:
This is almost ready but I would like to know what users of the
"floating submodule" think about this.
Thanks for working on this.
I do like to hear from potential users as well, because the general
impression we got was that floating submodules is not a real need of
anybody, but it is merely an inertia of people who (perhaps mistakenly)
thought svn externals that are not anchored to a particular revision is a
feature when it is just a limitation in reality. During the GitTogether'11
we learned that Android that uses floating model does not really have to.
Hi,
On Wed, Nov 09, 2011 at 10:01:33AM -0800, Junio C Hamano wrote:
Heiko Voigt [off-list ref] writes:
quoted
This is almost ready but I would like to know what users of the
"floating submodule" think about this.
Thanks for working on this.
I do like to hear from potential users as well, because the general
impression we got was that floating submodules is not a real need of
anybody, but it is merely an inertia of people who (perhaps mistakenly)
thought svn externals that are not anchored to a particular revision is a
feature when it is just a limitation in reality. During the GitTogether'11
we learned that Android that uses floating model does not really have to.
Since we did not get any reply from potential floating submodule users I
do not mind to drop this patch for now. It is archived in the mailing list
and it should be easy to revive once there is real world need for it.
Once we have the "exact" model support for checkout and friends this
might be a handy tool to update submodules before releases and such. But
currently I would like to focus on the "exact" front first.
Cheers Heiko
Hi,
On Wed, Nov 09, 2011 at 10:01:33AM -0800, Junio C Hamano wrote:
quoted
Heiko Voigt <hvoigt <at> hvoigt.net> writes:
quoted
This is almost ready but I would like to know what users of the
"floating submodule" think about this.
Thanks for working on this.
I do like to hear from potential users as well, because the general
impression we got was that floating submodules is not a real need of
anybody, but it is merely an inertia of people who (perhaps mistakenly)
thought svn externals that are not anchored to a particular revision is a
feature when it is just a limitation in reality. During the GitTogether'11
we learned that Android that uses floating model does not really have to.
Since we did not get any reply from potential floating submodule users I
do not mind to drop this patch for now. It is archived in the mailing list
and it should be easy to revive once there is real world need for it.
Once we have the "exact" model support for checkout and friends this
might be a handy tool to update submodules before releases and such. But
currently I would like to focus on the "exact" front first.
Cheers Heiko
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. We have several repositories for our common code
(commonA.git, commonB.git, etc) and a few different products that leverage these
common repos (productA.git, productB.git, etc). 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. (Obviously when development of the product stabilizes we would want to
change to anchoring to a specific sha1 in the common repos).
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:52:36
(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
This is almost ready but I would like to know what users of the
"floating submodule" think about this.
>
I do like to hear from potential users as well, because the general
impression we got was that floating submodules is not a real need of
anybody,
Floating modules are something much sought after by those who use Git
for non-development purposes, like those who have most of their $HOME
versioned with Git [1]. For example, part of what Joey Hess's `mr` tool
[2] does is to simulate floating submodules for Git-versioned $HOMEs.
In the context of versioned $HOMEs, or with backups in general, precise
tracking of submodules updates is not that important. To quote [3]:
«Last, change tracking is a bit more lenient with home directories. I
may shuffle some stuff around, and I don't need to explain the changes
to anyone else.». In my case, I want my ~/Documents dir (that is in a
different repo from $HOME) to be always updated; I would prefer not to
deal with submodule updates, merges and detached HEADs.
Bye,
[1] http://vcs-home.branchable.com/
[2] http://kitenet.net/~joey/code/mr/
[3] http://joshcarter.com/productivity/svn_hg_git_for_home_directory
--
Gioele Barabucci [off-list ref]