Bug#820494: origtargz: leaves "upstream" files in "master" after invocation

[Christoph Berg]

Re: Dmitry Smirnov 2016-04-09 <1639699.INnWnnHQ89 at 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