On 29/10/14 12:08, Ian Jackson wrote:
> The contents of the default ignore
> list is in dpkg-source, but it is not enabled unless the caller says
> -I. git-buildpackage passes -I.
To be completely clear (because I misread it twice in a row), you mean
that it is not enabled unless the caller uses «-I» with no argument,
which git-buildpackage does? (No literal strings «-I.» anywhere.)
> dgit's build options specify (either
> directly or via whatever helper they're using) -i\.git/ -I.git
This seems appropriate for the model you encourage with dgit, where the
git tree is identical to the unpacked .dsc.
dpkg-source's -I is currently equivalent to
-I*.a -I*.la -I*.o -I*.so -I.*.sw? -I*/*~ -I,,* -I.[#~]*
-I.arch-ids -I.arch-inventory -I.be -I.bzr -I.bzr.backup
-I.bzr.tags -I.bzrignore -I.cvsignore -I.deps -I.git
-I.gitattributes -I.gitignore -I.gitmodules -I.hg -I.hgignore
-I.hgsigs -I.hgtags -I.shelf -I.svn -ICVS -IDEADJOE -IRCS -I_MTN
-I_darcs -I{arch}
according to dpkg-source --help.
I suspect that the reason .gitignore is included in that list is so that
maintainers who build from git, but whose upstream does not, can drop a
/.gitignore into their git tree, as the maintainer of xwit appears to
have done, without it being managed as a Debian patch to the upstream
source code. It is necessary that it appears at top-level, because
otherwise it wouldn't have the desired effect; but it is an
implementation detail of how the Debian maintainer chose to set up their
VCS, so presumably they don't consider it to be something that should be
in the .dsc (where it would have to be handled as a quilt patch, or as
part of the diff.gz for format v1).
Obviously, this directly conflicts with dgit's view of the world, in
which the git repository and the unpacked .dsc correspond 1:1.
I think debian/source/local-options is going to be another potential
pain point for dgit: it is deliberately not included in a .dsc because
that would defeat the object of those options being local.
> It does seem to me to imply that using
> git-buildpackage to do an NMU is risky, because:
>
> If some user of git-buildpackage (without dgit) tries to do an NMU of
> a package containing .gitignore, it will remove the .gitignore.
In non-native packages, if there's a /.gitignore in the orig.tar.gz, I
think gbp would leave it alone? (The only other option would be to add a
quilt patch that explicitly removes it, or add a patch-band for it in
the v1 diff.gz, which seems unlikely.)
Your reasoning would seem to be true for native packages and for
/debian/.gitignore though.
I would personally hope that NMUers always do a source debdiff before
uploading, to confirm that they only made the changes they intended to
make; but perhaps not everyone is that conscientious.
On 29/10/14 09:47, Dimitri John Ledkov wrote:
> Ideally "packaging .gitignore" would be in debian/gitignore, but I
> don't know if that will work.
debian/.gitignore (which is presumably what you meant) can only be used
to ignore files under debian/. So you can do
echo "/tmp" > debian/.gitignore
echo "/hello" >> debian/.gitignore
echo "/*.debhelper" >> debian/.gitignore
echo ".*.swp" >> debian/.gitignore
and it will ignore debian/tmp, debian/hello, debian/*.debhelper,
debian/.*.swp and debian/**/.*.swp (in rsync notation) but will not
ignore, for instance, src/.hello.c.swp.
The story might be different if your upstream puts /.gitignore in (what
you use as) the .orig.tar.* archive?
I suspect that a lot of upstreams have a .gitignore, but don't put it in
their tarball releases, on the basis that the tarball is not a git
checkout. I certainly don't, although I'm considering it (it would make
it easier for distro maintainers to cherry-pick patches that happen to
add a new binary to .gitignore).
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5450e7bc.6050...@debian.org
