"pre-commit" hook to make sure users are committing all of their changes

[benthayer]

People can get confused about the staging area:

• They create a file and think "git commit" will already know about it and will commit it
• They create a file, then add it, then go on to make further modifications, thinking that git now knows about it

We can solve this by telling them "Git Gud has blocked your commit because your staging area is not the same as your working directory."

[sahansk2]

@benthayer Do you think it's possible to design a level where we tell the user that it's possible to commit added changes while still having changes not staged for commit with a git hook? Maybe something like this:

1. The user starts off with a clean working tree.
2. The user makes a new file (let's say a.txt).
3. The user adds that file.
4. The user then creates a new file (let's say z.txt).
5. The user then runs git commit -m "Add only a.txt"
6. Using a pre-commit hook for this particular level, we check if the user has successfully committed a file while having unstaged changes (z.txt), and if they did, we tell them Good job! Notice how you still have an unstaged file etc. etc. Now run "git gud test" in the output of that hook. (Otherwise, we tell the user to try again.)

• Implementation note: we could perhaps create a file in the .git/gud directory for this particular level when the commit hook runs successfully so that git gud test can just check for the existence of that file.

7. The user then runs git gud test, and the level is marked complete.

I remember we talked about a level like this at some point, but we didn't consider using git hooks for it.

[benthayer]

@sahansk2 How do you think this fits into #253?

[sahansk2]

@benthayer I think it fits well, but we'd have to set up a system to have certain git hooks for certain levels. Might be something worth looking into after the current edition of #253.

[benthayer]

Yeah, I think it'd be possible to have each level define its own hooks.

I'm not sure which levels will want custom hooks and which will want generic hooks, so that would be worth looking into.

We could do this pretty easily by loading the current level, then attempting to call a custom hook. For example, there might be BasicLevel.pre_commit, which will be called.

To start off, we could write the pre_commit.py to call BasicLevel.pre_commit, and then go from there. What do you think?