Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]

[P Baker <me@retrodict.com>]

I'll paraphrase to see if I understand your points:

*Moving objects from submodule .git directories into the base .git/
directory would protect the submodules and is a good idea.
*Moving to a .git/ file from .gitmodules should be taken off of the
goal list (I went back and read this thread:
http://thread.gmane.org/gmane.comp.version-control.git/78605; seemed
to clear things up).
*git submodule recurse would be a good option (not as a default), if
the remaining issues are resolved.
*It would be a good idea for git submodule to work with foreign VCS,
through Daniel's patches.

I appreciate the guidance, it's helping me to see that some of this
work has already been done, it needs to be finished and pushed into a
public release. As an intense user of submodules, what does it do
poorly/not do for your needs?

Thanks,

Phillip Baker

On Tue, Mar 31, 2009 at 7:05 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 31 Mar 2009, P Baker wrote:
>
>> On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> >> *move objects of submodules into base .git/ directory
>> >> **This would, as I understand it: protect submodules from being
>> >> overwritten and changes lost when switching between branches of the
>> >> superproject that might or might not contain the submodules and
>> >> centralize their management into one location.  The added benefits of
>> >> fully using git's ability to branch and merge submodules makes it
>> >> worth adding some complexity within the .git directory.
>> >
>> > The main problem with renaming/deleting is not the repository of the
>> > submodule, but the working directoy.
>> >
>>
>> My understanding is that since the submodule objects (history) is
>> stored in a .git directory in the subdirectory where the submodule is
>> located, removing that subdirectory during checkout of a branch that
>> does not include that submodule eliminates the .git directory as well.
>> Moving the objects from the submodule's .git directory to the base
>> .git directory would seem to alleviate this problem.
>
> My point was more about "you cannot just remove the subdirectory, or you
> _will_ lose data".
>
>> >> *use .git instead of .gitmodules
>> >> **I actually don't know why this was included with the project
>> >> description, I searched for an explanation of the desired name change
>> >> on the mailing list and in commit messages, but came up with nothing.
>> >
>> > AFAICT somebody thought that the information about the locations of the
>> > submodules should be in .git/ rather than in the working directory.  But
>> > of course, that is wrong: you want it to be tracked.
>>
>> So, in looking back through the archives of the mailing list there
>> seems to be some disagreement between using .gitmodules and
>> .git/config to track submodules.
>
> No.  .gitmodules has the default information, and "git submodule init"
> brings that into .git/config, to be overridden by the user if she so
> likes.
>
>> >> *git submodule update --init should initialize nested levels of submodules
>> >> **As an ease of use command, either an additional flag to recurse can
>> >> be added, or it can act by default. As a requested feature on the
>> >> mailing list, this is worth implementing.
>> >
>> > I thought there was a patch to support "git submodule recurse"?  That
>> > would be rather less limited than yet another option to submodule update.
>>
>> There is a git submodule foreach command, but it doesn't look like the
>> patch for git submodule recurse
>> (http://marc.info/?l=git&m=120997867213008&w=2) has been incorporated
>> into a public release.
>>
>> That is one route, on the other hand, the default action is also open
>> to question. When I update a submodule, I would probably expect that
>> anything it depends on is also updated. The default action probably
>> should be recursive.
>
> No.  Not at all.  At least in my usage, submodules are mostly optional.
> IOW I have ways in my projects to cope with the absence of a checkout.
>
>> >> *ability to update submodule pulled from svn repo
>> >> **One workaround is to clone it as local copy using git-svn and then
>> >> import that local clone as a submodule; clearly a clunky solution.
>> >> There are many requests for this feature (see
>> >> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
>> >> for a typical example), and it makes sense integrating git-submodule
>> >> with git-svn would expand submodule's usefulness.
>> >
>> > I do not think that this would be good.  Both "git svn" and "git
>> > submodule" are rather complex by now, and mixing them would only
>> > complicate code.
>>
>> Hm, point well taken, but it would seem to have enormous benefit for a
>> lot of people. I can move it down the priority list, but I'd like to
>> include it in the proposal - complexity alone isn't a good reason to
>> avoid something.
>
> Complexity is often a good sign of bad design.
>
> In this case, I want to point out that there has been a better design
> already:
>
> http://thread.gmane.org/gmane.comp.version-control.git/114545
>
> (Unfortunately, Daniel decided to post the follow-up patches in different
> threads; that will make it hard for you to find them.)
>
> Ciao,
> Dscho
>
>