.gitignore is not very complete

[the-maldridge]

I'll readily admit that I opened this issue solely to mention that your provided gitignore does not have an entry for emacs.

That being said you might be interested in https://gitignore.io, which I have found to be a very complete source for .gitignore files. For example, gitignore.io generates the following when I plugged in the basic parameters of your existing configuration:

# Created by https://www.gitignore.io/api/vim,c++,emacs,macos,python

### C++ ###
# Prerequisites
*.d

# Compiled Object files
*.slo
*.lo
*.o
*.obj

# Precompiled Headers
*.gch
*.pch

# Compiled Dynamic libraries
*.so
*.dylib
*.dll

# Fortran module files
*.mod
*.smod

# Compiled Static libraries
*.lai
*.la
*.a
*.lib

# Executables
*.exe
*.out
*.app

### Emacs ###
# -*- mode: gitignore; -*-
*~
\#*\#
/.emacs.desktop
/.emacs.desktop.lock
*.elc
auto-save-list
tramp
.\#*

# Org-mode
.org-id-locations
*_archive

# flymake-mode
*_flymake.*

# eshell files
/eshell/history
/eshell/lastdir

# elpa packages
/elpa/

# reftex files
*.rel

# AUCTeX auto folder
/auto/

# cask packages
.cask/
dist/

# Flycheck
flycheck_*.el

# server auth directory
/server/

# projectiles files
.projectile

# directory configuration
.dir-locals.el

### macOS ###
*.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon

# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### Python ###
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# C extensions

# Distribution / packaging
.Python
env/
build/
develop-eggs/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
*.egg-info/
.installed.cfg
*.egg

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*,cover
.hypothesis/

# Translations
*.mo
*.pot

# Django stuff:
*.log
local_settings.py

# Flask stuff:
instance/
.webassets-cache

# Scrapy stuff:
.scrapy

# Sphinx documentation
docs/_build/

# PyBuilder
target/

# Jupyter Notebook
.ipynb_checkpoints

# pyenv
.python-version

# celery beat schedule file
celerybeat-schedule

# SageMath parsed files
*.sage.py

# dotenv
.env

# virtualenv
.venv
venv/
ENV/

# Spyder project settings
.spyderproject
.spyproject

# Rope project settings
.ropeproject

# mkdocs documentation
/site

### Vim ###
# swap
[._]*.s[a-v][a-z]
[._]*.sw[a-p]
[._]s[a-v][a-z]
[._]sw[a-p]
# session
Session.vim
# temporary
.netrwhist
# auto-generated tag files
tags

# End of https://www.gitignore.io/api/vim,c++,emacs,macos,python

Its overkill on many many levels, but I've found it much more convenient to use than trying to remember all the things I need to ignore every time I add something to the build pipeline.

[rblack42]

My students typically have not worked with Linux, Git, or Make, and I try to get them started with all of those in my classes. Most show up with a basic Windows PC, a few with Macs, and most have never even seen the command line. My classes are their second or third course in programming.

I admit the project material is not "professional grade", but these beginners need to explore basic concepts before just getting the right way dropped on them. Most of them only know an IDE like Dev-C++ or (shudder) Visual Studio! My class is a no-IDE zone. Gitignore is one place I try to work with them to explain why we need to keep certain things out of repos.

As for emacs, not my religion. I introduce them to Vim. In over 15 years at this, I have only had one emacs user show up in class. I let them pick their editor, but I have used a variant of Vim for as long as it has been around, on just about every platform from a Pi to a Cray-2. I tried emacs way back when, and it made my head hurt. YMMV!

Thanks for the information. I will use it as a reference.

Roie

On Thu, Aug 24, 2017 at 12:20 AM, Michael Aldridge <notifications@github.com

wrote:

I'll readily admit that I opened this issue solely to mention that your provided gitignore does not have an entry for emacs.

That being said you might be interested in https://gitignore.io, which I have found to be a very complete source for .gitignore files. For example, gitignore generates the following when I plugged in the basic parameters of your existing configuration:

Created by https://www.gitignore.io/api/vim,c++,emacs,macos,python

C++

Prerequisites

*.d

Compiled Object files

.slo .lo .o .obj

Precompiled Headers

.gch .pch

Compiled Dynamic libraries

.so .dylib *.dll

Fortran module files

.mod .smod

Compiled Static libraries

.lai .la .a .lib

Executables

.exe .out *.app

Emacs

-- mode: gitignore; --

~ ## /.emacs.desktop /.emacs.desktop.lock .elc auto-save-list tramp .#

Org-mode

.org-id-locations *_archive

flymake-mode

_flymake.

eshell files

/eshell/history /eshell/lastdir

elpa packages

/elpa/

reftex files

*.rel

AUCTeX auto folder

/auto/

cask packages

.cask/ dist/

Flycheck

flycheck_*.el

server auth directory

/server/

projectiles files

.projectile

directory configuration

.dir-locals.el

macOS

*.DS_Store .AppleDouble .LSOverride

Icon must end with two \r

Icon

Thumbnails

._*

Files that might appear in the root of a volume

.DocumentRevisions-V100 .fseventsd .Spotlight-V100 .TemporaryItems .Trashes .VolumeIcon.icns .com.apple.timemachine.donotpresent

Directories potentially created on remote AFP share

.AppleDB .AppleDesktop Network Trash Folder Temporary Items .apdisk

Python

Byte-compiled / optimized / DLL files

pycache/ .py[cod] $py.class

C extensions

Distribution / packaging

.Python env/ build/ develop-eggs/ downloads/ eggs/ .eggs/ lib/ lib64/ parts/ sdist/ var/ wheels/ .egg-info/ .installed.cfg .egg

PyInstaller

Usually these files are written by a python script from a template

before PyInstaller builds the exe, so as to inject date/other infos into it.

.manifest .spec

Installer logs

pip-log.txt pip-delete-this-directory.txt

Unit test / coverage reports

htmlcov/ .tox/ .coverage .coverage. .cache nosetests.xml coverage.xml ,cover .hypothesis/

Translations

.mo .pot

Django stuff:

*.log local_settings.py

Flask stuff:

instance/ .webassets-cache

Scrapy stuff:

.scrapy

Sphinx documentation

docs/_build/

PyBuilder

target/

Jupyter Notebook

.ipynb_checkpoints

pyenv

.python-version

celery beat schedule file

celerybeat-schedule

SageMath parsed files

*.sage.py

dotenv

.env

virtualenv

.venv venv/ ENV/

Spyder project settings

.spyderproject .spyproject

Rope project settings

.ropeproject

mkdocs documentation

/site

Vim

swap

[.]*.s[a-v][a-z] [.]*.sw[a-p] [.]s[a-v][a-z] [.]sw[a-p]

session

Session.vim

temporary

.netrwhist

auto-generated tag files

tags

End of https://www.gitignore.io/api/vim,c++,emacs,macos,python

Its overkill on many many levels, but I've found it much more convenient to use than trying to remember all the things I need to ignore every time I add something to the build pipeline.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rblack42/project_template/issues/2, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_80twrTMpXtcShkAYthIljpU4Zpk5Sks5sbQgrgaJpZM4PA5zM .

[the-maldridge]

Fair enough. I would still suggest adding the executable name though to the gitignore, since the repository currently has binary data checked into it (and possibly even using a filter-branch statement to rewrite history since you are the sole contributor).

[rblack42]

Adding the executable name is problematic since this is a template. With no extension on that file it is difficult to identify it until the template gets modified for a real project. Maybe I need a script that converts the project into a real one and takes care of that. (Hmmm, ansible could do that!) And the binary files are probably not really needed in the template. I put them there during the class I created this for. Roie

On Thu, Aug 24, 2017 at 9:44 PM, Michael Aldridge notifications@github.com wrote:

Fair enough. I would still suggest adding the executable name though to the gitignore, since the repository currently has binary data checked into it (and possibly even using a filter-branch statement to rewrite history since you are the sole contributor).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rblack42/project_template/issues/2#issuecomment-324809509, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_80rtQjhXhcw7XVlr_JZ6wx2up7CJHks5sbjUKgaJpZM4PA5zM .

[the-maldridge]

Ansible could do that but it would also be fantastic overkill. I suggest a make rule that does the following:

grep "$(PRGM)" .gitignore || echo "$(PRGM)" >> .gitignore

This should handily solve the issue without a student needing to run an ansible command to make sure things are up to date. Of course if you mandate a binary name its moot and ansible would be a fine solution.

[rblack42]

Good idea. The only issue I have is dealing with commands like this on Windoze. Getting all the "right" tools (like grep) installed is not hard, but training the students in their use is. I go back and forth between teaching them how all this works, and just giving them a solution. "Copy and Paste" teaches you nothing!

Roie

On Fri, Aug 25, 2017 at 1:40 PM, Michael Aldridge notifications@github.com wrote:

Ansible could do that but it would also be fantastic overkill. I suggest a make rule that does the following:

grep "$(PRGM)" .gitignore || echo "$(PRGM)" >> .gitignore

This should handily solve the issue without a student needing to run an ansible command to make sure things are up to date. Of course if you mandate a binary name its moot and ansible would be a fine solution.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rblack42/project_template/issues/2#issuecomment-325004969, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_80pVDqTRwug2TTqNFq0WvJRrftJ2pks5sbxUcgaJpZM4PA5zM .

[the-maldridge]

I think when I learned grep it was explained to me as "Ctrl-F but you can use it without needing to open the file". A gross oversimplification, but it was enough that I understood how to use it at the time. I still don't really use grep with regex, but that's largely because $dayjob has more specialized tooling.

[rblack42]

I assume you work for GitHub, based on this discussion. I am working on some code to use the new API to make managing my classes easier. I really wish the classroom documentation was better. Controlling student access permissions seems weak for academic use.

My students are very new to any kind of professional level development work, and I spend a lot of time introducing them to the "tools of the trade" they should learn about. Back before Git became popular, I used svn in my classes and am probably the only instructor (out of 65 in this department) even mentioning source code control. On the other hand, I installed my first Unix OS on a VAX 11-780 back in 1984, then later on a Cray-2 supercomputer. I ended up the Director of that facility! Cool to have a machine like that as my PC! I am working now on some computational fluid dynamics code I want to run on the NCAR Yosemite Supercomputer, if I can figure out how to keep 77,000 processors busy! Should be a blast!

Roie

On Fri, Aug 25, 2017 at 9:30 PM, Michael Aldridge notifications@github.com wrote:

I think when I learned grep it was explained to me as "Ctrl-F but you can use it without needing to open the file". A gross oversimplification, but it was enough that I understood how to use it at the time. I still don't really use grep with regex, but that's largely because $dayjob has more specialized tooling.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rblack42/project_template/issues/2#issuecomment-325075325, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_80iUgmqO0kwldUiffpXk56MGMHjsdks5sb4NBgaJpZM4PA5zM .

[the-maldridge]

I actually don't work for GitHub, I just have experience with some exceedingly large code bases and managing them with Git. As far as the classroom management stuff goes, well you're already far ahead of the University I studied at for even teaching some tooling at all. That being said, you might take a look at some of the other players out there (I don't really think its in good taste to mention them on a thread here on GitHub).

I will certainly agree that learning the tools of the trade is both incredibly important and can be very difficult. The learning curves of common editors came to mind: https://qph.ec.quoracdn.net/main-qimg-d71d592cd66fbdebb470e55996feb207-c.

We all had to start somewhere...