2

In trying to write a pre-receive hook which rejects certain kinds of changes to certain kinds of files, I am stumped as to why the following is legal in that script:

git show <new_commit>:<file>

as is used in this example (after having teased out the affected files using diff with --name-only), but not

git diff <old_commit> <new_commit> -- <file>

I prefer the latter so that I only reject changes introduced rather than patterns already existing in the files, but it generates the error: "unknown revision or path not in the working tree" when executed from this script.

I suspect it has to do with the ordering of events, since both work at the command-line on my bare repo, but would like to understand the distinction.

Community
  • 1
  • 1
John Lehmann
  • 7,975
  • 4
  • 58
  • 71

1 Answers1

-3

As the answer you linked points out, when the pre-receive hook is executed, no files have been received yet, only which refs should be updates (details on this and other hooks can be found on the githooks(5) manpage).

Since there is no data with which your old data could be compared, no diff can be created.

Community
  • 1
  • 1
Nevik Rehnel
  • 49,633
  • 6
  • 60
  • 50
  • 1
    But if no file has been received yet, how can "show :" work? – John Lehmann Dec 12 '12 at 16:49
  • 1
    @JohnLehmann what exactly does `git show :` print when you call it from that script? Can you paste an example output somewhere? – Nevik Rehnel Dec 12 '12 at 23:56
  • The linked answer is wrong. It is not the case that 'pre-receive' means that the files have not yet been received. – jwg Nov 26 '14 at 11:04
  • 1
    @jwg, yup that's right, the manpage says as much. Must've seen something wrong back then. Feel free to edit the answer, since I don't currently have time to properly research it. – Nevik Rehnel Nov 26 '14 at 17:14