okay, i've looked into things a bit more but i think it's doable. to isolate the problem i've thrown together a simple shell script run on a test repo to sanity check it (see below).
There's requirement about submodules matching is slightly more relaxed
now. the debian branch must have a superset of the submodules in the
upstream branch (at least i couldn't figure out a way to get ls-files to
work without cd'ing into the submodule... i suppose we could clone it to
an outside tempdir if it didn't exist). the submodules do not have to
be the same version or branch, but they do have to point at the same
remote (this might be a limitation in submodules themselves), and in
this code at least they must have everything already fetched (this could
be changed later, or at least caught). This works recursively too.
Anyway, now that I have a PoC and a general plan of attack, I guess
tomorrow I will take a stab at incorporating this into gbp proper!
#!/bin/sh
set -e
ubranch=master
ls_submodule() {
local prefix mode objtype hash name
prefix="$1"
while read mode objtype hash name; do
fullname="${prefix:+$prefix/}$name"
if [ "$objtype" = "commit" ]; then
echo $fullname:$hash
( cd $name 2>/dev/null &&
git ls-tree $hash | ls_submodule "$fullname"
) || ( echo "submodule $name not available?" >&2 && exit 1 )
fi
done
}
submodules=`git ls-tree $ubranch | ls_submodule ""`
echo subs: $submodules
signature.asc
Description: This is a digitally signed message part
