On Thu, 13 Sep 2018 at 15:57:48 +0100, Ian Jackson wrote:
> Looking more narrowly, it seems to me that: including the .gitignore
> (say) is sometimes helpful, and never harmful. So stripping it out is
> simply a mistake.
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:
- 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).
- 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).
(I personally agree that .gitignore and other .git?* files ought to be
considered part of a source package, particularly debian/.gitignore,
and accordingly I have debuild configured to use -I.git rather than -I;
but my opinion is not the only valid one.)
smcv
