Control: tags -1 confirmed
Hi. Thanks for the report. I'm sorry that you're finding dgit has
done xsomething inconvenient.
gregor herrmann writes ("Bug#1056103: dgit fills up my disk with
.git/dgit/unpack directories"):
> Recently I noticed that my usage of `dgit --gbp push-source' leaves
> .git/dgit/unpack directories in each touched package directory. Which
> in my case amounts to 1.5 GB below my pkg-perl directory (for more
> than 1100 dgit-pushed packages since 2019).
Ah. I hadn't really considered this kind of use case. (I obviously
touch smaller packages, or fewer different packges, or sometbing.)
I think the wasted space ought to be be O(the size of the source
package), although constant factor may be 2 or 3. Is this not the
case for you ? If there are cases where dgit has wasted much more
space then that would be straightforwardly buggy I think.
You're right that these directories are not really needed after dgit
has completed. However, they can be useful for debugging failures.
Another future run of dgit would remove it of course, but would just
leave another one. And there's no central tracking and they're hidden
in .git so you wouldn't normally see them and know to delete them.
So, yes, I can see the problem and I agree that something better
should be done.
I think there are some tradeoffs involved, so may not entirely
straightforward. Some thought will be needed. (Some of the things in
.git/dgit are hardlinked from elsewhere, so it's not as simple as
using TMPDIR instead.)
Perhaps dgit should, by default, clean up this stuff just before it
exits successfully, but leave it behind for debugging failures.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
