You mentioned to use shallow clones of the upstream repo, but there is a flaw in your thoughts.
You can't use shallow clone for pushing etc, see man git-clone
(For conveiniance, I included the relevant section here:)
--depth <depth> Create a shallow clone with a history truncated to the specified number of revs. A shallow repository has number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you want to only look at near the tip of a large project with a long history, and would want to send in a fixes as patches.
So I think what you suggested in the FAQ won't work.
dpkg-source avoids using git push (or clone) for this reason. --Joey
(Sorry, I didn't have an OpenID and was too lazy to get one right now, so I got an
anonymous OpenID. If you want to reach me, extract my mailaddress (rot13 encrypted)
with "echo email@example.com|tr A-Za-z N-ZA-Mn-za-m" )
Very interesting. It allows lots of things, but I think in the end it is going to be unworkable to use shallow repos as source packages. However, a shallow clone could be made from a debian mirror to deliver source for building. Will standardization of the repo be made/required from the guidelines? To keep special branches for debian/ stuff and original source. And special debian tags in the history. Perhaps it could be possible for dpkg-source tools to list the included versions in the package and allow building any version included. --http://engla.myopenid.com/