© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
Hi,
I may be missing the obvious here, but can't we just rely on pristine-tar for cases (1) and (3)? My git-ubuntu clones have these pristine-tar branches:
remotes/
remotes/
By doing for example
git branch --track pristine-tar pkg/importer/
pristine-tar can be used to checkout an unmerged orig tarball from Debian. Unfortunately the pristine-tar branch name is hardcoded in the pristine-tar cli, so this manual step is needed. There is a feature request to add support for specifying branch name to pristine-tar:
https:/
which has been filed specifically for git-ubuntu by this Scott Moser guy :-)
As Bryce mentioned uscan can't be trusted to download the same .orig tarball which is in the archive. For example for the packages I maintain in Debian I use d/watch only for getting notified of new upstream releases, but then I package with a "pure git" workflow (using gbp-import-ref [1]), so the uscan downloaded tarball differs from what I upload. In general I think re-downloading the .orig tarballs where "blessed" ones exist is not a good idea.
Case (2) is certainly a valid use case for `uscan -d`, however I wonder if downloading those "ahead of Debian" orig tarballs belongs to git-ubuntu. [Maybe git-ubuntu could one day support merging from upstream in a "pure git" way, automatically setting up an `upstream` branch using the Vcs-Git field?]
[1] https:/