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

Felipe Sateler fsateler at debian.org
Thu Aug 11 13:24:22 UTC 2016


On 11 August 2016 at 04:43, IOhannes m zmölnig (Debian/GNU)
<umlaeute at debian.org> wrote:
> 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...

I am less annoyed by this because I have set export-dir set in my
~/.gbp.conf. Thus gbp builds never happen in the git tree, and thus
never contain the build artifacts.

>
> 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

I have lately been migrating to gbp pq instead of quilt to manage the
patches. In addition to allowing easier workflows for eg, rebasing on
new upstream versions, this nicely sidesteps the issue of the .pc dir.
Paired with the use of export-dir, this results in the .pc dir never
existing in my local worktree.



-- 

Saludos,
Felipe Sateler



More information about the pkg-multimedia-maintainers mailing list