.gitignore (was Re: Help offered with xwax package)

[IOhannes m zmölnig (Debian/GNU)]

On 2016-08-10 11:52, James Cowgill wrote:
>> Actually we should repack ( to get rid of upstream .gitignore file and
>> > use our .gitignore file ) and rename.
> You don't actually need to do that (and arguably you should not repack
> orig tarballs unless you need to). For source format "3.0 (quilt)",
> dpkg-source contains a set of regexes for files which are automatically
> ignored when generating the final source package. .gitignore (and .git/)
> are on the list so any changes you make to upstream's .gitignore are
> completely ignored by dpkg-source.

i was wanting to ask about best practices regarding .gitignore for some
time.

when packaging, i have two "problems" with .gitignore

#1 upstream includes a .gitignore
having an upstream .gitignore field usually just creates trouble as it
(mostly) hides stray artefacts lying around until dpkg-source comes and
complains. i really think that gitignore's main purpose is exactly this
hiding of build artefacts, but it mainly causes trouble when it comes to
Debian's build chain.
with my Debian hat on, i would like to get rid of all upstream
.gitignore files, ideally *automatically* (to catch all those gitignores
in subdirectories...)
with my upstream hat on, i desparately need .gitignore though...

a "solution" which i often find applied (by myself, and others like
mira) is to just strip away the .gitignore file, when repacking the
sources (though afaik this is only done when the sources are repackaged
anyhow)

#2 ignoring Debian toolchain artefacts
most packages use "3.0 quilt", which I (unlike many others) have no
problems with.
unfortunately, using quilt results in a .pc/ directory in the project
root, something that gbp will loudly complain about.

the most common "solution" is to add .pc/ to .gitignore



now my problem is, that i heartily dislike both of these solutions.
the two reasons if found for my dislike are:
- they modify files outside of debian/, which i think is a no-go (where
does it end?), or at least ugly as hell.
- they add cruft to each and every package to solve a common problem.

i have (very unsystematically) tried to solve this problem in a more
central manner over the last few years, the idea being that this can
either be solved in the toolchain involved (gbp) and/or via some local
configuration on my computer that applies to "all Debian repositories".

for #1, i came up with something along the lines of [1], which basically
just ignores .gitignore on a per-repo basis (configured via `git config`)
in a way it works, but has some unwanted side-effects (like a no-longer
working tab-completion for git)

for #2 i was happy to see that recent versions of gbp (currently in
experimental) sport a postclone hook [2], which can be used to run
various repository tasks right after cloning.
i now use this to gitignore "/.pc/" via .git/info/exclude (not touching
the .gitignore file).

unfortunately the two proposals clash (ignoring .gitignore really means
ignoring all gitignore(5) files, including .git/info/exclude).


so i'm not sure about a proper "best practice" to deal with this.
i could imagine something like:

- add ".gitignore" to the Files-Excluded stanza in d/copyright *without*
warranting a "~repack" suffix in the version (i guess this is justified,
since dpkg-source ignores the file anyhow).
even better would be to nag the developers of gbp to just not include
this file on import-orig (i'm not sure about the prospects of this
suggestion though).
- suggest (in [3] to use a postclone hook that ignores Debian-toolchain
artefacts via .git/info/exclude
even better would be to nag the developers of gbp to automatically
ignore /.pc/ if the source-format is "3.0 quilt"  (i've already done
that [4], but it seems that with the advent of postclone hooks they
think this is none-of-their-business).

what do others think*?

fgmasdr
IOhannes



[1] http://stackoverflow.com/questions/25909293
[2] https://bugs.debian.org/812816
[3] https://wiki.debian.org/DebianMultimedia/DevelopPackaging
[4] https://bugs.debian.org/812815

* apart from "don't you have other problems?"