On Sat, Jan 09, 2010 at 11:29:41PM +0300, Alexey Gladkov wrote:
> On 09.01.2010 23:19, Max Ivanov wrote:
> > How to deal with git submodules? Upstream uses them in some places and
> > I don't know how to put their content in the final source tree prior
> > to %build stage. Is it even possible?
> 
> I did support for submodules, but gear's upstream don't want it.
> 
> http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodule

The main idea behind GIT submodule is that it allows weak references.
These objects (gitlink tree entries) refer to commit objects which are
allowed to be missing from the git repository.  Regular git tools like
git-fetch, git-push and their derivatives do not follow such references.
To complete a full git checkout for a tree containing submodules,
additional commands (e.g. "git submodule update") need to be executed
to fetch required commit objects from external git repositories.

For example, GNU coreutils project uses gnulib submodule:
http://git.savannah.gnu.org/cgit/coreutils.git/plain/.gitmodules

The main idea behind gear is to reproducibly extract archive from a
given git repository.  gear (in its basic form) takes a git repository,
a commit id, and outputs a tarball.  Every commit object referenced by
the given commit id must be extractable from the given git repository.
Now imagine that this commit id uses submodules and required external
commit objects are missing, because no git repository that uses
submodules is required to be self-contained.  In this case, gear would
have to attempt to fetch these commits from internet.  This is NOT
reliable, and gear would not be able to guarantee reproducibly.

As you see, there is a fundamental problem: GIT submodule breaks
repository completeness, but gear requires git repositories to be
self-contained.  I have no idea how to avoid this problem.


-- 
ldv