On Sat, Feb 14, 2009 at 4:03 AM, Lars Hjemli <hjemli@xxxxxxxxx> wrote:
> On Sat, Feb 14, 2009 at 06:17, Eric Kidd <git@xxxxxxxxxxxxxxx> wrote:
>> On Fri, Feb 13, 2009 at 11:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> Eric Kidd <git@xxxxxxxxxxxxxxx> writes:
>>>> ...
>>>> If the submodule has moved around the source tree, specify one or more
>>>> values for alternate_dir. To specify the URL of the newly created
>>>> repository (for use in .gitmodules), use the --url parameter.
>>>
>>> Unfortunately, I do not think we have designed fully (nor implemented at
>>> all) behaviour to check out different points of history that has the same
>>> submodule moved around in the superproject tree.
>>>
>>> There were several unconcluded discussions done in the past (and I admit I
>>> participated in a few of them), but it may be hard to use the resulting
>>> repository out of this tool.
>>
>> Thank you for looking at this proposal!
>>
>> I think that the resulting repository is usable (though it could
>> certainly be better). In particular, the following commands will
>> always give you a working checkout:
>>
>> git checkout any-version
>> git submodule update --init
>>
>> The unit tests for git-submodule-split.sh actually walk through the
>> entire history and run 'git submodule update --init' at each revision.
>> This works correctly because git-submodule-split creates the necessary
>> .gitmodules entries for each revision, and includes the
>> submodule.*.url value that you specify.
>>
>> Unfortunately, this means that whenever the submodule moves to a new
>> location in the tree, 'git submodule --init' will actually have to
>> clone it again. That's not a perfect situation, but it will work for
>> reasonably small submodules.
>
> <hand-waving>
> I didn't look at the patch, but if the submodule uses a single
> module-name while moving around, the re-cloning problem would by
> solved if the submodule git-dir was stored inside the git-dir of the
> containing repository (by using the git-file mechanism). Maybe I
> should try to finally implement this...
> </hand-waving>
We use submodules at my workplace to keep track of a variety of
closely-related projects (branched from each other). On account of
some deficiencies in the interface of the GIT we're using (including a
few that are still present), we have a bunch of custom scripts to
clone and check out the whole mess, but it goes something like this:
In super/.git/config in a checkout:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
push = +refs/heads/*:refs/heads/kmoffett-branches/*
fetch = +refs/projects/heads/*:refs/projects/remotes/origin/*
push = +refs/projects/heads/*:refs/projects/heads/kmoffett-branches/*
[submodule "projects/FOO"]
url = ./projects/FOO/.git
In super/.gitmodules:
[submodule "projects/FOO"]
path = projects/FOO
url = ./projects/FOO/.git
In sub/.git/config (IE: super/projects/FOO/.git/config)
[remote "origin"]
url = ../..
push = +refs/heads/*:refs/projects/heads/FOO/*
fetch = +refs/projects/heads/*:refs/remotes/parent/*
fetch = +refs/projects/remotes/*:refs/remotes/*
[remote "parent"]
${same as remote.origin}
In sub/.git/objects/info/alternates (IE:
super/projects/FOO/.git/objects/info/alternates)
../../../../.git/objects
In this environment, basically *all* objects are kept in the
"superproject". When doing a local commit into a subproject, the new
objects are first stored there (is there any way to change that?), but
on the first "git push" in the subproject they will be pushed up to
the parent's objects directory and the next GC of the child project
will clean them up. All of the child branches are stored in
"refs/projects", so they don't show up by default in various "git
branch", etc, commands, but it's trivial to ensure they get pushed and
pulled appropriately.
Essentially the "superproject" consists of our project-management
environment, with the subprojects being each individual project, which
may be entirely independent. There is a relatively tight feature
coupling between the per-project scripts and the version of the
management environment, so this works out relatively nicely for our
uses.
A clone by default will only get the superproject, if you want
subprojects you have to add the appropriate branch refs to the
.git/config file (as seen in the above example). This is handy if
you're only working on one of the particular projects. Having them
all as separate branches cloned from each other does make it very easy
to diff/merge/cherry-pick between them, even though they are
effectively independent.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
