The git command uses the file .gitignore to learn about files whose changes doesn't matter.
Do you have one to share?
Also, anyone up for the challenge of adding a default one for Racket on Github?
2 Likes
raco pkg new (or whatever the syntax is) produces a default .gitignore:
3 Likes
Nice! I did not know that. FWIW, here's the content of that file:
*~
\#*
.\#*
.DS_Store
compiled/
/doc/
1 Like
With the exception of the last 2 entries, though, most of what you get from this is that we tend to use Emacs on macOS....
I had that in my email; apparently it did not come through
Yes; in fact, it might be nicer to omit those things and let folks configure them globally, so that the default is just
compiled/
/doc/
Examples: .gitignore all the .DS_Store files in every folder and subfolder - Stack Overflow, GitHub - tpope/vim-pathogen: pathogen.vim: manage your runtimepath, Dotfiles/gitignore_global at master · benknoble/Dotfiles · GitHub
2 Likes
The relevant repo is here.
Anyone interested in making a pull request on behalf of Racket?
1 Like
Some of those are files that DrRacket creates. It might make sense to put in the standard set that Racket Mode, DrRacket, and the language server-supported IDEs tend to do?
2 Likes
Done
1 Like
I'm not sure about ignoring .#* files? I left a comment on the PR just now.
I’ve updated the PR to remove these lines
\#*
.\#*
1 Like
@greghendershott: do you think that https://github.com/racket/racket/blob/master/racket/collects/pkg/private/new.rkt#L119 should be changed as well? If so, I suggest that we do that first, since it will justify the change for the PR.
1 Like
Pull request created
-
I'm not sure I understand the full context/intent/spirit for the
github/gitignorerepo? But it looks like they have a set of language templates, and a separate set of "global" templates for e.g. editors. (Including one for Emacs -- which includes\.#so they don't share my opinion; that's fine.)So it seems like, as @benknoble and @jbclements were saying, it would make more sense for a Racket language
github/gitignoreto focus solely on the Racket files. Justcompiled/and/doc/, IIUC? -
As for the
raco pkg newtemplate, I think that can set its own rules. It's not trying to be some ideal taxonomy of curated.gitignorefiles, like thatgithub/gitignorerepo. Instead it's trying to help people create a new package; it could err on the side of including more things. Personally, I would try to include more things in my own.gitignore, to cover contributors using various operating systems and editors.
3 Likes
This is what it says at github/gitignore:
This is GitHub’s collection of
.gitignorefile templates. We use this list to populate the.gitignoretemplate choosers available in the GitHub.com interface when creating new repositories and files.
— GitHub - github/gitignore: A collection of useful .gitignore templates
I was taking that to mean you will be able to select Racket when you use the ‘new repo’ action.
1 Like
@spdegabrielle From that description, plus from looking at some of the top-level, language .gitignore files in that repo: It seems like github/gitignore would want the file for Racket to be only the things unique to Racket, which I guess is just:
compiled/
/doc/
It seems like their intent is that people would populate a global gitignore from things in the /Global directory of that repo.
As for raco pkg new, I think it's OK for it to have a different policy than github/gitignore.
Assuming it continues to include some OS- and editor-specific things like .DS_Store and *~ (which I personally think is fine) I just have the (tiny) opinion that it no longer include the .\# pattern for Emacs "lock files".
I personally recommend to anyone who hasn't done so, to configure their own global gitignore to ignore things like this, on their computer for all git repositiories. Mostly because it is convenient, you only have to do it once (instead of for every repository) and then you don't have to hope that somebody has included the things that annoy you (which they shouldn't have to do anyway, because those are unbounded and platform/editor specific)
I think adding these platform specific things in a git repo template is like giving somebody a fish, instead of teaching them how to fish. The global gitrepo config enables everyone to change it to their liking without imposing unnecessary "boilerplate" repetitive configuration for every repository.
That said sometimes you just want a warm meal without cooking it yourself, so I can understand the desire to go with the "feels wrong, but slightly easier to use" solution.
1 Like
I agree about teaching people to fish! OTOH I'm also sympathetic to projects feeling they don't have time to use pull requests as a teaching opportunity.
For example I'd find it hard to argue with a project that adds .DS_Store files to its .gitignore if they keep getting those in PRs.
(For Racket Mode for Emacs I even supply a .dir-locals.el to guide contributors about things like tabs, whitespace, final newlines, etc. 
)
2 Likes
I wonder how easy/difficult it would be to instead write a git hook that rejects those files and gives an error message about using global gitignore and removing those from the commit. I think that would be what I would try to do in that situation. So far I didn't need git hooks so I am not very familiar with them.
Also might be nice if platform specific git packages for example via homebrew had pre-configured those files to be ignored. Even better would be if programs didn't pollute directories with lots of tempfiles.
Imagine there was something like a "gensym" for filesystem pathes, an opaque capability like unique value and filesystems could somehow contain those as subdirectories and put all their application specific files in there. This way nobody would have to see those .DS_Store files. There might be a lot of other ways to handle this, but it irks me that this filesystem centric approach leaks data that should not be seen (caching should be transparent/invisible). A whole other thing is the potential for conflicts / exploits between applications. But I am ranting to much and getting off topic. 
1 Like