Re: Dmitry Smirnov 2016-04-09 <1639699.INnWnnHQ89@deblab> > On Saturday, 9 April 2016 12:14:00 PM AEST Christoph Berg wrote: > > Sorry, this is just plain wrong. origtargz does not look into git > > branches. If any of the backends used do that, which backend is used? > > What's the point of saying that origtargz doesn't do what it does?
Hi, what you are seeing here is not garbage left behind from whatever operation on the upstream branch, it's simply the orig tarball unpacked (step 2). > > Where? How do they look like? Paste an example please. Step 1: > pristine-tar: successfully generated ../cadvisor_0.22.2+dfsg.orig.tar.xz > > Step 2: > Unpacking ../cadvisor_0.22.2+dfsg.orig.tar.xz > > > At this point unpacked tarball contents left in "master"; > "git status" show untracked files. Right, but this is exactly what's documented, and what origtargz is supposed to be doing - give you a full working tree to work on. If the upstream source is already there, it doesn't overwrite it (unless with --unpack), but if it isn't it unpacks it. > Problem is not happening if I run "origtargz --unpack=no" so I'm suggesting > to alter defaults to avoid unpacking when origtargz invoked from git > repository... I hope that make sense. Thanks. Using origtargz to simply generate (fetch, copy, ...) the tarball to .. is a legitimate use case, but you'll need to pass --unpack=no to disable the automation on "almost empty" directories. I thought I had also implemented a ORIGTARGZ_UNPACK option for ~/.devscripts but it seems I forgot to do that. I'll also update the manpage to make the --unpack=once behavior more clear. Christoph
