abort if there are unstaged changed files

[sfahlberg]

Hi there,
I am looking for a way to abort overcommit's checks if there are unstaged commits. Is there any functionality currently available that will do that?

[jawshooah]

May I ask why? Overcommit stashes unstaged changes before running pre-commit hooks, so they shouldn't be having any effect on them.

[sfahlberg]

@jawshooah it's functionality we currently have in our commit hooks. What if we just wanted a warning if you had unstaged commits?

Does it stash pop the changes once the hooks run?

[sds]

@sfahlberg yes, the stashed changes are popped so that your working tree is restored to its previous state.

Also, to clarify, you meant "unstaged changes", not "unstaged commits," right? There's no such thing as an "unstaged" commit unless I'm missing something (just want to make sure I understand the request).

Pre-commit hooks will only run against changes which have been added to the index. Unless you have some sort of work flow where you explicitly want to prevent your developers committing their staged changes while there are unstaged changes to tracked files, Overcommit's method of stashing your unstaged changes before running pre-commit hooks should suffice here.

[sfahlberg]

yeah, I meant unstaged changes. Good to know about the stashing.

Is there a way to display a warning that there are unstaged changes? @sds

[jawshooah]

@sfahlberg I think that's a bit outside the scope of Overcommit. It's not uncommon at all to have unstaged changes when you commit, and there's nothing inherently dangerous about it, so it would be strange for us to warn about it.

Ideally you should be using a command prompt that reports the status of the repo you're in after every command, e.g. bash-git-prompt.

[sds]

It's not currently possible to warn if there are unstaged changes. I agree with @jawshooah that this is also bit odd to enforce. I personally work within a repo with unstaged changes all the time. I have a hard time seeing this being useful rather than just being noisy, but your development process may just be very different. In general, my experience tells me that hooks that "warn" are ignored and your developers will not see much value from such a hook.

[themattman]

There are two types of "unstaged changes":

1. A file is modified and not staged
2. A file is modified, staged, and then modified again. So there exists staged and unstaged changes for that file.

A visual representation of these two cases:

$ git status -s
 M file1
MM file2

If a hook makes modifications to files, the git-stash approach will break for case 2 above. For a hook to make changes to a file, it must then git-add the file after making changes. I haven't been able to find a way to git-add specific lines of a file programmatically. It's all-or-none when scripting git-add.

I'm not familiar with Overcommit enough to know whether hooks modify files. If hooks never make changes to the underlying staged files, then you can ignore my comment :)

Edit: Ah, I see that hooks that modify files is not supported re: #238. This is an important consideration when thinking about adding that feature.

[sds]

If a hook makes modifications to files, the git-stash approach will break for case 2 above.

Yes, this is an important point, @themattman, and it's one of the reasons why #238 has not been implemented. To get that fully right would take some very careful planning and consideration, requiring time which I personally don't have at the moment.

Very open to a well-tested pull request that addresses #238. I'm closing this issue in favor of that one. Thanks for your feedback!