Hi, On Sun, Sep 09, 2018 at 05:50:52PM +0200, Raphael Hertzog wrote: > Hi, > > On Sun, 09 Sep 2018, Guido Günther wrote: > > > pristine-tar copes just fine with this and fallsback to use the data from > > > origin/pristine-tar but if the compression method is not the usual gzip, > > > gbp > > > buildpackage will fail. I have to tell it "--git-compresionn=xz" to make > > > the call succeed. It would be nice if the code that looks up the > > > compression > > > method in the pristine-tar branch was smart enough to also fall back > > > to looking into origin/pristine-tar. > > > > What about debian/pristine-tar, salsa/pristine-tar, foo/pristine-tar and > > other > > variants? What if these have different versions already to pick from? If > > somebody comes up with a good heuristic and sane defaults this might be > > an option but I consider using gbp clone way safer. > > Why not using the remote repository associated to the debian packaging > branch? > > $ git config --get branch.master.remote > origin
That could be used as a fallback (although I've seen enough weird setups where this wouldn't help either). > And why assume that there would be conflicting versions in other > remotes? Because that's what I've seen a lot. I've seen more repos with stale pristine-tar commits (or commits of the same tarball with different compression types) than ones without a local branch tracking the "wanted" remote. > I think the current failure mode is unhelpful, few newbie users would > understand the nature of the problem. I totally agree that it's hard for newbies. That's why I said I'm happy to apply a patch for this. Cheers, -- Guido
