benthayer / git-gud

Wanna git gud? Then get git-gud, and git gud at git!
MIT License
401 stars 42 forks source link

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

Open benthayer opened 3 years ago

benthayer commented 3 years ago

People can get confused about the staging area:

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 commented 3 years ago

@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 commented 3 years ago

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

sahansk2 commented 3 years ago

@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 commented 3 years ago

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?