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

Thanks for the comments, my replies are included. It's good to see
some core folks are big users!

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

Hi,

I am a rather intense user of submodules, so I am quite interested.

I'm curious, where/under what circumstances do you tend to use it?

Please take my comments as encouragement rather than discouragement.

Always.

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.

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.

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.

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.

I also believe that the workaround described, if incorporated into
git-submodules.sh in an appropriate way might open up possibilities
for further improvement. The UI would change much, seems like it'd
just be detection of pointing to a SVN repo instead of a git repo and
then hooking into git svn calls instead of regular git calls. This
brings up the possibility that git submodules should abstract its
repository handling in much the same way that git does. I'm not
familiar with the code, but this seems more like calling other
plumbing hooks than anything else.

quoted

*make submodules deal with updated references
**Instead of issuing merge conflicts on updated submodule references,
this will allow submodules on default detached HEAD so that changes
from the local repo can be committed without first pulling changes
from the shared repo.

I'd rather call this "make git-submodule help with merging".

Better name. Duly noted. Will change.

quoted

*protect changes in local submodules when doing “git submodule update”
**This is similar to the previous point, in that changes need to be
protected or merged or warnings issued when updating the submodule.
The potential to lose work with no warning is a big no-no.

One word: Reflogs.

I  haven't used reflogs, but it doesn't seem to fix the problem (maybe
you can explain?): simply knowing where/what the reference is, doesn't
mean that git-submodule looks at it, obeys the reference or issues
warnings when it should. The problem as stated
(http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1211380200000#c3897235118548537475)
was that git submodule update would silently overwrite any local
changes with the remote version (i.e. git did not check to see if the
local reference was different than the remote reference when
updating).

quoted

*make git submodules easy to remove
** See http://pitupepito.homelinux.org/?p=24, for an example of why
this is a pain. Adding a submodule has ui, removing one should as
well.

AFAIR there was already a patch to implement this, but the OP apparently
did not address all issues.

Yep, found it on the mailing list. Obviously, part of the project
would be to resolve those final issues.

Phillip Baker