severity 851679 wishlist
tags 851679 + upstream
clone 901897 -1
retitle -1 dgit fails autopkgtest: true/false are no valid
working-tree-encodings
reassign -1 dgit 5.0
retitle 901897 git needs Breaks against dgit versions without
working-tree-encoding support
block 901897 by -1
quit
Hi Ian,
Ian Jackson wrote:
> Subject: git introduces new hazardous working-tree-encoding attribute
This title doesn't describe a bug. On first reading, I thought you
were saying that some working-tree-encoding related feature was
behaving incorrectly, but it doesn't appear to be so. (I was trying
to understand so that I could forward this report upstream.)
By the way, is there a way to trigger these autopkgtests automatically
with git from experimental as well? That way, I'd get earlier notice
about these issues.
> So, on to the actual problem:
>
> Looking at the manpage for gitattributes(7) it mentions a new
> attribute
> working-tree-encoding
> which affects the way files are checked in and out.
>
> dgit and similar workflows need to disable this attribute, because
> they require that git trees and source packages correspond, which
> cannot be achieved if working trees made from source packages are not
> identical to git trees once committed.
I think you're saying that attributes like "text" are forbidden in
dgit packages because dgit wants to compare the content of the working
directory to the tracked content without using Git for that. Am I
understanding correctly?
Git has a notion of "smudge" and "clean" attributes. The idea is that
to get the content for the worktree, you use "smudge". To get the
checked-in content, you use "clean". Would dgit be able to
interoperate with that?
In the dgit(7) manpage, you write:
These transformations are context-sensitive and not, in
general, reversible
Strictly speaking, since users can configure filters that run
arbitrary commands (see "filter" in gitattributes(5)), that's true,
but the transformations are meant to produce a canonical "smudged"
form in the worktree and a canonical "clean" form in the repository.
Sorry I missed bug#851679 before. We can discuss this more there.
Perhaps some command like "git archive" would work better than "git
checkout" for this use.
> In #851679 I requested a way to disable all checkout-affecting
> gitattributes. This has not yet been done AFAICT.
>
> In lieu of that, dgit's test suite has a specific test to spot when
> new attributes are introduced. It tries enabling them and seeing if
> things go wrong. And indeed, that test has now tripped. (It failed,
> in fact, simply because some of the values it attempted to set the
> unknown working-tree-encoding attribute to were invalid, but IMO the
> test has done its job.)
>
> I think at the very least I will need to update dgit to disable
> working-tree-encoding as well. I think the new git should probably
> have a Breaks against the older dgit.
Happy to add a Breaks. Do you know what version of dgit will have the
fix?
Thanks,
Jonathan
