On Sun, Dec 02, 2012 at 12:03:24PM -0800, Russ Allbery wrote: > 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.
Also the --git-pristine-tar-commit option might help with a) since it saved the extra step of comitting the pristine-tar delta. I don't see any actual way we can improve (c) either but am open to suggestions. Cheers, -- Guido > > -- > 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