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

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

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

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?

-- 
see shy jo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

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

[Junio C Hamano]

Joey Hess <joey@kitenet.net> 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.

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

[Jonathan Nieder]

Junio C Hamano wrote:
> Joey Hess <joey@kitenet.net> 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?

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. :)

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

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

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

[Dmitry Potapov]

On Wed, Nov 10, 2010 at 11:45 PM, Joey Hess <joey@kitenet.net> 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

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

[Jan Hudec]

On Thu, Nov 11, 2010 at 01:17:04 +0300, Dmitry Potapov wrote:
> On Wed, Nov 10, 2010 at 11:45 PM, Joey Hess <joey@kitenet.net> 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.

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 <bulb@ucw.cz>

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

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

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

[Junio C Hamano]

Joey Hess <joey@kitenet.net> writes:

> ... 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.

I am hearing "list of files in the commit message", and am getting
confused.  As far as I know we don't store such a list in the commit
message.

Puzzled.

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

[Kevin Ballard]

On Nov 11, 2010, at 2:03 PM, Junio C Hamano wrote:

> Joey Hess <joey@kitenet.net> writes:
> 
>> ... 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.
> 
> I am hearing "list of files in the commit message", and am getting
> confused.  As far as I know we don't store such a list in the commit
> message.
> 
> Puzzled.

I believe he means in the # comments at the bottom of the editor. They
contain the output of `git status` as a reminder of what you're
committing.

-Kevin Ballard