Arguments to git hooks

Arguments to git hooks

[jaseem abid]

Hello all,

I am trying to write a hook '.git/hooks/commit-msg' to be run before
every commit.

How can I pass arguments to the script? Now by default the only arg I
am getting is `.git/COMMIT_EDITMSG'`. I would love to get the list of
files I tried to commit also into the script so that I can run a lint
program on it before committing it. How can I get this done?

V/r,

--
Jaseem Abid
http://jaseemabid.github.com

Re: Arguments to git hooks

[Marcus Karlsson]

On Mon, May 07, 2012 at 12:05:51AM +0530, jaseem abid wrote:
> Hello all,
> 
> I am trying to write a hook '.git/hooks/commit-msg' to be run before
> every commit.
> 
> How can I pass arguments to the script? Now by default the only arg I
> am getting is `.git/COMMIT_EDITMSG'`. I would love to get the list of
> files I tried to commit also into the script so that I can run a lint
> program on it before committing it. How can I get this done?
> 
> V/r,

As far as I can see that's the only argument that git-commit passes on
to the commit-msg hook. Can't you just call something like git-status
from the hook or do you need the information passed specifically as an
argument?

	Marcus

Re: Arguments to git hooks

[jaseem abid]

On Mon, May 7, 2012 at 12:42 AM, Marcus Karlsson <mk@acc.umu.se> wrote:
> As far as I can see that's the only argument that git-commit passes on
> to the commit-msg hook. Can't you just call something like git-status
> from the hook or do you need the information passed specifically as an
> argument?

I can always get last commit from `.git/COMMIT_EDITMSG'` - a fixed
file. Isn't passing that as an argument a bit pointless? I want files
I tried to commit specifically passed in as an argument.

Are you suggesting me to run some plumbing command, parse the result
and get the required data ? Is there an easier way to get this done?


-- 
Jaseem Abid
http://jaseemabid.github.com

Re: Arguments to git hooks

[Marcus Karlsson]

On Mon, May 07, 2012 at 12:48:35AM +0530, jaseem abid wrote:
> On Mon, May 7, 2012 at 12:42 AM, Marcus Karlsson <mk@acc.umu.se> wrote:
> > As far as I can see that's the only argument that git-commit passes on
> > to the commit-msg hook. Can't you just call something like git-status
> > from the hook or do you need the information passed specifically as an
> > argument?
> 
> I can always get last commit from `.git/COMMIT_EDITMSG'` - a fixed
> file. Isn't passing that as an argument a bit pointless?

That's a good question. I don't know. If someone else knows the reason I
sure would like to find out.

> I want files I tried to commit specifically passed in as an argument.

There are many different reasons to use hooks. If everything that a hook
could potentially need was passed to it as an argument then a lot of
data would often end up unused. Better to supply as little as possible
and only do more work when it's actually needed.

> Are you suggesting me to run some plumbing command, parse the result
> and get the required data ? Is there an easier way to get this done?

I wouldn't go as deep as the plumbing, I think git status --porcelain
should work just fine, the output is fairly easy to parse.

	Marcus

Re: Arguments to git hooks

[jaseem abid]

On Mon, May 7, 2012 at 2:41 AM, Marcus Karlsson <mk@acc.umu.se> wrote:
> There are many different reasons to use hooks. If everything that a hook
> could potentially need was passed to it as an argument then a lot of
> data would often end up unused. Better to supply as little as possible
> and only do more work when it's actually needed.

That seems like a good reason not to pass all of the data, but isn't
the file names the most primary thing somebody can ask for?

>> Are you suggesting me to run some plumbing command, parse the result
>> and get the required data ? Is there an easier way to get this done?
>
> I wouldn't go as deep as the plumbing, I think git status --porcelain
> should work just fine, the output is fairly easy to parse.

I have always wondered why 'git status --porcelain' is giving a
'plumbing' style output. Any docs on this somewhere?

-- 
Jaseem Abid
http://jaseemabid.github.com

Re: Arguments to git hooks

[Jeff King]

On Mon, May 07, 2012 at 12:05:51AM +0530, jaseem abid wrote:

> I am trying to write a hook '.git/hooks/commit-msg' to be run before
> every commit.
> 
> How can I pass arguments to the script? Now by default the only arg I
> am getting is `.git/COMMIT_EDITMSG'`. I would love to get the list of
> files I tried to commit also into the script so that I can run a lint
> program on it before committing it. How can I get this done?

It sounds like you want the "pre-commit" hook rather than "commit-msg".

But that aside, the solution is to use plumbing commands to examine the
state. You probably want "git diff-index --cached --name-only" to get
the list of files that are being committed.

-Peff

Re: Arguments to git hooks

[Jeff King]

On Mon, May 07, 2012 at 03:10:07AM +0530, jaseem abid wrote:

> On Mon, May 7, 2012 at 2:41 AM, Marcus Karlsson <mk@acc.umu.se> wrote:
> > There are many different reasons to use hooks. If everything that a hook
> > could potentially need was passed to it as an argument then a lot of
> > data would often end up unused. Better to supply as little as possible
> > and only do more work when it's actually needed.
> 
> That seems like a good reason not to pass all of the data, but isn't
> the file names the most primary thing somebody can ask for?

Yes, although keep in mind that the list of files does not necessarily
fit onto the command line. We would have to feed it over stdin, and then
you would have parsing/quoting issues.

But you can get the exact same list from "git diff-index --cached
--name-only", and it is exactly as hard to parse as stdin would be (and
you can even decide to use "-z" to eliminate the quoting issues).

So asking the user to call the plumbing command is more efficient and
more flexible, but not actually any harder to use.

> > I wouldn't go as deep as the plumbing, I think git status --porcelain
> > should work just fine, the output is fairly easy to parse.
> 
> I have always wondered why 'git status --porcelain' is giving a
> 'plumbing' style output. Any docs on this somewhere?

It is plumbing. The porcelain is meant to be "output suitable for
reading by porcelains". Although I was the person who named "git status
--porcelain", it is not a convention I think is particularly good; I
named it to be consistent with other git commands which have a
"--porcelain" mode.

-Peff

Re: Arguments to git hooks

[Andrew Sayers]

On 06/05/12 19:35, jaseem abid wrote:
> Hello all,
> 
> I am trying to write a hook '.git/hooks/commit-msg' to be run before
> every commit.
> 
> How can I pass arguments to the script? Now by default the only arg I
> am getting is `.git/COMMIT_EDITMSG'`. I would love to get the list of
> files I tried to commit also into the script so that I can run a lint
> program on it before committing it. How can I get this done?

First, a standard warning - consider using a pre-receive hook instead of
a pre-commit hook.  A lot of git's power comes from making commits as
cheap as possible, so rules like "no committing until your code is
pretty" tend to stifle people.  For example, I often commit changes
before running lint-type operations, then use `git add -p` and `git
checkout -p` to selectively accept/reject individual changes.  When I'm
done, I `git commit --amend` to pretend the original commit never
happened.  A pre-receive hook gives you most of the same guarantees as a
pre-commit hook with almost none of the cost.

Having said that, there are situations where pre-commit hooks are a good
idea (like catching "DO NOT COMMIT" comments).  I've played with this a
little before, and never found a very satisfactory solution.  Here are
some important cases:

# git status will sometimes tell you the file that will be committed:
# edit foo
git add foo
git commit


# git status will sometimes need a bit of careful parsing:
# edit foo
# edit bar
git add foo
git commit


# git status sometimes tells you the right file but the wrong contents:
# edit foo
git add foo
# edit foo again
git commit


# but often git status will tell you the wrong file altogether:
# edit foo
# edit bar
git add foo
git commit bar


The best solution I've found is a `git commit` wrapper that does
something like `CHANGES="$(git commit $@ --dry-run -v)"` to get a
reliable diff, then starts work from there.

	- Andrew

Re: Arguments to git hooks

[jaseem abid]

On Tue, May 8, 2012 at 3:47 AM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:
> On 06/05/12 19:35, jaseem abid wrote:
>> Hello all,
>>
>> I am trying to write a hook '.git/hooks/commit-msg' to be run before
>> every commit.
>>
>> How can I pass arguments to the script? Now by default the only arg I
>> am getting is `.git/COMMIT_EDITMSG'`. I would love to get the list of
>> files I tried to commit also into the script so that I can run a lint
>> program on it before committing it. How can I get this done?
>
> First, a standard warning - consider using a pre-receive hook instead of
> a pre-commit hook.

I am trying to get a lint, commit message spell checker, trailing
whitespace check in code etc work on my *local machine* before
committing. pre-receive works in the server right? Its also time I
need to seriously consider a pre-commit hook to "Reject commits made
between 4am and 7am with a note to go to bed."

> A lot of git's power comes from making commits as
> cheap as possible, so rules like "no committing until your code is
> pretty" tend to stifle people.

Its ok since I am the only one to use it because I want to make my
commits cleaner and better.  There is always --no-verify for skipping
hooks.

> The best solution I've found is a `git commit` wrapper that does
> something like `CHANGES="$(git commit $@ --dry-run -v)"` to get a
> reliable diff, then starts work from there.

Isn't `git commit $@ --dry-run --porcelain` better for parsing or am I
missing something ?

-- 
Jaseem Abid
http://jaseemabid.github.com