Simon McVittie writes ("Re: Bug#908747: Default -I and -i option should not
exclude .<vcs>ignore"):
> I didn't implement this feature, so I could be wrong, but my understanding
> is that the rationale for making it convenient to ignore .gitignore,
> .bzrignore and friends is:
I think in fact that it was not so considered a decision, but that
doesn't matter because we should consider counterarguments on their
merits. So...
> - Some maintainers do have upstream source, but it's an import of the
> orig tarball created by Autotools `make dist` or equivalent, which
> very rarely includes .gitignore even if upstream originally had one;
> so they want to create ./.gitignore (possibly a copy of the one from
> upstream's VCS) to ignore build products. If that was included in the
> source package, (see above).
On Salsa, this is the most common way of working I think. (I haven't
done a survey.)
But there is a serious problem with this argument. In this scenario,
the maintainer *is using the .gitignore as part of the source code*.
They use it to ignore build products. Someone who imports the dsc
into git (there are various tools that do this - not just dgit) wants
that .gitignore too, for the same reason.
It is true that in this scenario (with `3.0 (quilt)') the maintainer
would need to make a patch to include .gitignore.
But this hypothetical maintainer's argument is, ISTM, simply: "It is
slightly inconvenient to supply the proper source code because I have
to manage this bit of source code in a way that publishes it
properly." When I look at it like that it seems obviously very wrong.
The fact that this bit of source code is of relatively minor
usefulness (and used to be of even more minor usefuless) does not
really address this serious problem of principle.
Now I think it is unarguably true (in your example scenario) that the
.gitignore is part of the source code, if we take "source code" to
mean "the preferred form for modification" (as the GPL does and as we
usually do in Debian).
But even if you don't take that view, it is certainly true that the
.gitignore is useful for some users and that the inconvenience of
shipping it as a patch is very small. This does not seem like a
proper tradeoff to me.
> - Some maintainers don't have upstream source in their VCS at all (more
> or less ubiquitous before wide adoption of git, and still sometimes done
> even with git), so they want to unpack the upstream source into their
> packaging-only git repository and create a ./.gitignore to ignore it
> for git purposes. If that was included in the source package, it would
> enlarge the diff (1.0 format) or require creation of a new patch in
> the patch series (2.0 or 3.0 (quilt) format).
I think the argument based on this scenario is much less easy for me
to dispose of. I confess it hadn't previously occurred to me that
people might try to use .gitignore for this.
In this situation the .gitignore would presumably contain *all* the
upstream source. Ie it would say
**
!debian/**
or something equivalent.
In a .dsc that would not be useful; indeed, it would be harmful -
because anyone who receives such a .gitignore via the .dsc, and
subsequently experiences its effects, will be someone who has imported
the .dsc into git, upstream files and all. They will not want all the
upstream files ignored !
But: it doesn't seem to me that this scenario could have been the
motivation for the default ignore set in dpkg-source, because the
default ignore set applies to all source formats equally, and it is
only `3.0 (quilt)' for which this could possibly make any sense.
I have no idea what proportion of packaging-only repositories have a
root .gitignore at all, let alone one like this. I suspect it is very
rare, so this argumnt is theoretical. And someone with this workflow
has other options.
I hope this makes sense.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
