Quoting Sean Whitton (2017-11-24 03:39:28) > > I'd just like to avoid having to maintain a *second* git repository next to > > the dgit-repos. Isn't there a way to create a new empty upstream branch on > > the fly at the point where the maintainer wants to import a new upstream > > release? [...] Because at that point, the maintainer did "dgit clone" and > > has the current upstream tarball available which could be used to set up an > > upstream branch with just the old upstream version in it as a single > > commit, no? > I'm not sure whether or not something like this could be done. It breaks > assumptions of gbp-import-orig(1), which expects an upstream branch always to > be present. I understand your desire to avoid a second git repo, but I don't > want to incorporate that into the manpage. I want to keep the usage of > gbp-import-orig(1) as straightforward as possible, and that requires pushing > to alioth. > > I think you'll find that you will want to push to alioth anyway, for WIP > commits between uploads.
Your argument is sound. Thus, lets consider this bug being fixed once the use of a second git repo is detailed. Unfortunately we are getting rid of alioth these days so the documentation might have to change soon. XD Though it seems this problem will also resolve itself with #848678 at which point no secondary git repo is necessary anymore and the whole discussion about the disadvantage of one becomes moot. Thanks! cheers, josch
signature.asc
Description: signature
