Re: is it kosher for pre-commit to change what's staged?

Joey Hess [off-list ref] writes:

I've noticed that if I make a pre-commit hook change the files that are
staged, those changes are not reflected in the commit message. For
example, if a pre-commit hook git add's somefile, the commit message
won't reflect that. I guess prepare-commit-msg is being run before
pre-commit for some reason?

My intention was that Documentation/githooks.txt would document things
that are allowed (e.g. "applypatch-msg" explicitly says "The hook is
allowed to edit the message"), and anything that is not specifically
allowed is not.

"Is it kosher" is a difficult question to answer, as something may not be
allowed but there may not be an enforcement mechanism to deny it, iow, it
may happen to work by accident.

In general, pre-anything is about checking and denying and is supposed to
be free of side effects.

Junio C Hamano wrote:

Joey Hess [off-list ref] writes:

quoted

I've noticed that if I make a pre-commit hook change the files that are
staged, those changes are not reflected in the commit message. For
example, if a pre-commit hook git add's somefile, the commit message
won't reflect that. I guess prepare-commit-msg is being run before
pre-commit for some reason?

I'm guessing it is to allow cancelling a commit before a costly
pre-commit hook runs.

My intention was that Documentation/githooks.txt would document things
that are allowed (e.g. "applypatch-msg" explicitly says "The hook is
allowed to edit the message"), and anything that is not specifically
allowed is not.

"Is it kosher" is a difficult question to answer, as something may not be
allowed but there may not be an enforcement mechanism to deny it, iow, it
may happen to work by accident.

In this case, isn't it only a half accident?  For example, I think
v1.5.4-rc0~78^2~12 (builtin-commit: fix partial-commit support,
2007-11-18) taught git to support this a little better.

That said, I would be interested to hear the use case, since modifying
staged content on the fly for a commit sounds a little crazy. :)

Jonathan Nieder wrote:

In this case, isn't it only a half accident?  For example, I think
v1.5.4-rc0~78^2~12 (builtin-commit: fix partial-commit support,
2007-11-18) taught git to support this a little better.

Partial commits modified by pre-commit still don't work entirely right IME.
After the commit, the index is such that git wants to revert any changes
added to the commit by the pre-commit hook.

That said, I would be interested to hear the use case, since modifying
staged content on the fly for a commit sounds a little crazy. :)

Well, with git-annex (which I should probably properly announce here
sometime), large files are not committed to git, but instead a symlink
pointing at the content is committed. That symlink can temporarily be
replaced with a copy of the file when the user wants to modify it, and
if the user then commits, it's nice if it can move away the large file's
content, and arrange for the commit to contain an updated symlink pointing
at the new content.

That said, since git commit stages the whole large file into the index,
which is the kind of expensive operation git-annex exists to avoid,
it's still not very practical to intercept the commit like that. What
I ideally need is a hook that is run before git commit stages anything.


BTW, githooks says pre-commit is "invoked before obtaining the proposed
commit log message", which is a bit confusing. I actually see
prepare-commit-msg and commit-msg both called after pre-commit.

-- 
see shy jo

On Wed, Nov 10, 2010 at 11:45 PM, Joey Hess [off-list ref] wrote:

That said, since git commit stages the whole large file into the index,
which is the kind of expensive operation git-annex exists to avoid,
it's still not very practical to intercept the commit like that. What
I ideally need is a hook that is run before git commit stages anything.

Then maybe you should look at git smudge&clean filters. They perform
conversation between the working tree and the index.  Though I am not
sure how well they work with big files.


Dmitry

On Thu, Nov 11, 2010 at 01:17:04 +0300, Dmitry Potapov wrote:

On Wed, Nov 10, 2010 at 11:45 PM, Joey Hess [off-list ref] wrote:

quoted

That said, since git commit stages the whole large file into the index,
which is the kind of expensive operation git-annex exists to avoid,
it's still not very practical to intercept the commit like that. What
I ideally need is a hook that is run before git commit stages anything.

Then maybe you should look at git smudge&clean filters. They perform
conversation between the working tree and the index.  Though I am not
sure how well they work with big files.

The problem point is not big files, but whether they can change the file mode
associated with the entry, since in this case the tree contains a file, but
index should contain a symlink. Looking at the documentation, there does not
seem to be a way to do it.

It might be worth adding support for it now we have a use-case.

-- 
						 Jan 'Bulb' Hudec [off-list ref]

Jan Hudec wrote:

The problem point is not big files, but whether they can change the file mode
associated with the entry, since in this case the tree contains a file, but
index should contain a symlink. Looking at the documentation, there does not
seem to be a way to do it.

It might be worth adding support for it now we have a use-case.

I suppose that if I were using smudge filters, I'd probably not need to
use symlinks at all. I'll think about it.

It belatedly occured to me that I already had something else modifying
the index in pre-commit, and smudge filters cannot handle its use case.

That is, etckeeper (http://kitenet.net/~joey/code/etckeeper). The
pre-commit script there stores some metadata about files that git
usually doesn't track, by putting it in a dotfile, and stages that
dotfile for commit. Which currently works fine, except for the minor
problem that the user doesn't see the dotfile listed in the commit
message.

-- 
see shy jo