*.eps and *.svg .gitignore patterns match files in repo

[markdblackwell]

On Aug 25, 2015; 5:05pm James Lowe wrote:
> On 25/08/15 18:48, markdblackwell wrote:
>> Per
>> https://www.kernel.org/pub/software/scm/git/docs/gitignore.html

>> "A gitignore file specifies intentionally untracked files that Git
>> should ignore. Files already tracked by Git are not affected"

>> Aug 23, 2015; 6:21am, James Lowe wrote:
>>> I had similar problems when trying to add snippets in the doc for
>>> midi, i.e. any snippet ending in "-midi.ly"

>> Mark D. Blackwell wrote:
>>> Because of these patterns in the .gitignore's, Git will ignore
>>> changes to those files.

>> I misspoke. More accurately:

>> If a file is *already* in the repository, then its name matching a 
>> .gitignore pattern won't cause Git to ignore changes to it; Git
>> still will commit its changes easily.

>> Only *new* files which match a .gitignore pattern will be ignored,
>> silently.

>> If these particular new files have names (or extensions, or path
>> fragments, depending on the particular .gitignore pattern) similar
>> to files present in the repository, then this is confusing.

>> Aug 23, 2015; 6:35am David Kastrup wrote:
>>> Basically, having files both in the repository and in .gitignore
>>> is a recipe for trouble. The patterns should likely be made more 
>>> discriminatory.

>> In order to make the relevant patterns more accurately
>> discriminatory, we might identify the programs (that we use) which
>> generate noise files (i.e., files we want to exclude from the
>> repository) of these kinds, and in which directories. Does anybody
>> know?

>> Otherwise, we should try removing these particular .gitignore
>> patterns, and see whether our procedures still generate any of
>> these unwanted files—and in which directories. Then (obviously) we
>> can reinstate the patterns, and make them more discriminatory.

>> Here's what Git blame says is the latest commit which changed the
>> relevant lines in /.gitignore:

>> $ git blame .gitignore
>> 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100  2) *-midi.ly
>> 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100  9) *.eps
>> 915e0d52 (Jan Nieuwenhuizen 2006-12-05 14:54:32 +0100 26) *.svg

> Well I am not sure exactly what we're looking for but when I removed
> these entries in my .gitignore and then ran both an out of and in tree
> make doc, make test-baseline and a make check, I didn't get any files
> showing up when I then did a 'git status'.

> Is that good enough?

Now, I'm unsure exactly what you mean. Just to clear up one possibility
first, I suppose you might be asking whether this is a good enough test to
establish that these current lines in .gitignore are no problem. With that I
would disagree, for the reason David Kastrup stated.

Let me admit that I'm not expert on (all) the various tools used by (all
the) people who now, or in future, might work on LilyPond, and who might
submit patches for Rietveld review, or who might commit changes to the
master branch of LilyPond's repository on Savannah.

Therefore, regarding the question whether yours is a good enough *test* of
the safety of removing those two lines ("*.eps" and "*.svg"), I don't know.

Why are those lines in there? Usually people add patterns to .gitignore to
cover problematic files which arise in practice. Perhaps indeed those
patterns should be removed now, as you did in your test. This would simplify
.gitignore.

A more conservative approach would be to change them so that they ignore
files of those extensions, but only in the top-level directory. That might
cover such noise files as actually do arise naturally (maybe; I don't know).
So, the lines would be:

/*.eps
/*.svg

Have you seen this similar thread?:

http://lilypond.1069038.n5.nabble.com/build-gitignore-pattern-matches-files-in-repo-tt179867.html

Based on it, the pattern "build/" in .gitignore should be changed perhaps
to:

/build/

These three (3) changes to lines in .gitignore, if committed to the LilyPond
master branch on Savannah, would cover absolutely all the files of the
current repository (as of August 21, 2015, anyway), so that no file matches
a pattern in .gitignore. I believe this is what David Kastrup desires (see
above).



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/eps-and-svg-gitignore-patterns-match-files-in-repo-tp179828p180196.html
Sent from the Bugs mailing list archive at Nabble.com.