@exarkun set owner to Alex

Doesn't git have local configuration for this?

Twisted has no svn:ignore properties either. This is because svn lets the owner of a check decide which files they care about and which they don't. This is better than forcing a single list onto everyone.

	@hawkowl commented

Additionally, you need to ignore Trial directories (_trial_temp{number}).

	Alex commented

There are several advantages to having a .gitignore in Twisted:

• Some files cannot be globally ignored, because they're perfectly reasonable things, for example build/, I have several projects where that's a source directory in the repo, but in twisted it's a... build directory! Which should never be checked in.
• Further, this ensures a good default for people. The overwhelming convention in git seems to be for projects to ignore these things themselves, the result, therefore is a worse experience for new users.
• Finally, it ensures that these files are never checked it in. It servers as a simple backstop to make sure no one accidentally adds one of these files while doing a git add . or similar.

	@exarkun commented

Finally, it ensures that these files are never checked it in. It servers as a simple backstop to make sure no one accidentally adds one of these files while doing a git add . or similar.

Yet you're not proposing that *.pyc be ignored for everyone? There should never be a .pyc file checked in to Twisted, either.

	Alex commented

That was an oversight in my original patch (the new one has it), somehow my twisted dir didn't have any (I guess I'd cleaned it recently), so it slipped by mind.

	@Julian removed owner

I have all of these in my global gitignore, but I agree it might be nice to have. Other possible candidates:

dist
__pycache__/
.coverage
htmlcov

twistd.log
twistd.pid

.tags
tags

	@glyph commented

If we have policy indicating that certain types of files should never be checked in (like pyc files, lore output files, etc) then it seems sensible to reflect this policy mechanically with a .gitignore; it doesn't feel like "forcing" the decision on anyone, since if someone wants to make a fork that adds those types of file, they can always modify .gitignore entries in their fork. If they want to see build artifacts, there's git status --ignored. (It does seem like a bit of an oversight in git that you can't say "ignore .gitignore but still pay attention to core.excludesfile and .git/info/exclude", but maybe the fact that that's missing is a hint that nobody ever cares about that use-case in real life.)

There are also places where we have more information than a global ignore file could. One such place is when it's not the file's extension, but its location, which makes the difference as to whether it ought to be ignored. For example, ".html" files generated from Lore and from Pydoctor would be nice to have ignored, since the output from that process should never be checked in; but *.html is definitely not something I'd want to have globally ignored.

Personally, I've got a hack where my editor integration for generating Lore docs will currently do --config ext=.loreout.html for its lore invocation and then I have a global ignore for that funky extension, but that's impossible to discover (and maybe not reasonable to configure with other, future doc-gen tools like Sphinx) so that doc output stuff won't clutter my status output. I have pretty much 100% confidence that a new contributor who wanted this behavior would not be able to figure out how to do that in a reasonable period of time.

So it seems like it would leave the workflow basically unchanged for experienced contributors, but make it smoother for newcomers. Unless I've overlooked some use-case for having some build artifacts routinely show up in status output but others remain hidden? I can't remember the exact reason not to add svn:ignore properties, but I vaguely recall it had something to do with the fact that having them on some branches but not others produced nightmarish conflict resolution problems, because SVN properties exist in a bizarre netherworld. .gitignore, by contrast, is just a simple text file with normal conflict-resolution rules.

	@glyph set owner to @Julian

Julian, why did you remove Alex as the owner? Is there something else you'd like to do to respond to the review comment?

	@Julian commented

He added it for review, I assumed he forgot to unassign it.

Review-wise I think the first four of the ones in my last comment are worth adding too, otherwise again lgtm.

	@glyph commented

Replying to Julian:

He added it for review, I assumed he forgot to unassign it.

Right you are, I was reading the ticket's metadata incorrectly. (Thought it was still out of review.) Sorry.

Review-wise I think the first four of the ones in my last comment are worth adding too, otherwise again lgtm.

I would also be inclined to say it should be landed, unless exarkun wants to elaborate further on his objections.

	@exarkun commented

I am not convinced that putting ignore configuration into the repository is a good idea. This doesn't seem to be the majority opinion though and I don't feel like spending any more time arguing against this somewhat minor mistake.

	@glyph set owner to @glyph

OK, in that case, let's do it.

	@hawkowl commented

By the way, as above - if you run two instances of trial at the same time, it will make _trial_temp/ and _trial_temp-1/. If you run three, it will also make a -2. As I've had this show up in my Twisted directory, I think it's worth adding _trial_temp*/ instead - it seems to match both the regular and the numbered.

	Alex commented

Now handles that case.

	@glyph set status to closed

(In [39915]) Apply gitignore.diff from [#6731](#6731): add .gitignore

Author: Alex
Reviewer: glyph, Julian
Fixes: #6731

This adds a .gitignore to the repository, for the convenience of contributors
using git.

	@exarkun commented

Note that the most recent patch attached to the ticket is not what got committed to trunk.

	@hawkowl commented

Continued in #6736 with the changes I mentioned