Thomas Koch <tho...@koch.ro> writes: > I like to fork my git packaging repo from upstream and merge upstreams > history in my upstream branch from time to time. When upstream makes a > release, they hopefully tag the git commit from which their release was > made or I need to identify it manually.
> Then there are three cases: > a) Upstreams release tarball has identical content to one git > commit. (Maybe it was even created via git-archive.) > b) Upstreams release tarball has slightly other content then any git > commit. (b) is common for projects that don't check in generated files, but which include them in tarball releases. > c) Upstreams release tarball has a totally different structure then any > git commit. > In case a) I can just create a signed git tag "upstream/$VERSION" and > pristine-tar commit the tarball. > In case b) I'd create a new commit containing the tarballs content with > the release commit as its parent, tag it and merge it into master. > In case c) I'm doomed. > It would be nice, if git-import-orig would support this workflow > somehow. Well, I don't see any way to support (c) other than "don't base your upstream branch on upstream's Git repository, since it doesn't bear any relationship to the release." But for (a) and (b), I think the --upstream-vcs-tag option to git-import-orig will do exactly what you want. (b) was the workflow for which I originally requested it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
