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

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
[off-list ref] wrote:

Hi,

On Tue, 31 Mar 2009, P Baker wrote:

quoted

On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
[off-list ref] wrote:

quoted

quoted

*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".

quoted

quoted

quoted

*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.

quoted

quoted

quoted

*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.

quoted

quoted

quoted

*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