# rebase -i reword runs pre-commit hook with curious results

3 messages from 2012-02-01 to 2012-02-02. Participants: Neal Kreitzinger, Andrew Wong.
Thread: https://gitlist.dev/t/29507

## Neal Kreitzinger, 2012-02-01 21:50

Subject: rebase -i reword runs pre-commit hook with curious results
Message-ID: <jgcc3q$mvl$1@dough.gmane.org>
URL: https://gitlist.dev/e/jgcc3q%24mvl%241%40dough.gmane.org

```
I'm confused on why and/or how interactive rebase runs the pre-commit hook 
when doing the reword command for commit (a).  My pre-commit hook does 
keyword expansion on the worktree copy of the modified index files and then 
re-adds them to effect a user-date-stamp when committed.  However, the 
user-date-stamps don't get updated when reword runs the pre-commit hook. 
IOW, the pre-commit hook does not get the same results as if I were doing a 
commandline git-commit of a modified index.  I suppose reword is protecting 
the preservation of all the contents of commit (a) except the commit message 
which makes sense, but I don't understand how it goes about doing this while 
still attempting to somehow honor the pre-commit hook.  (git 1.7.1)

v/r,
neal 

```

## Andrew Wong, 2012-02-02 05:43

Subject: Re: rebase -i reword runs pre-commit hook with curious results
Message-ID: <4F2A2286.3090808@sohovfx.com>
URL: https://gitlist.dev/e/4F2A2286.3090808%40sohovfx.com
In-Reply-To: <jgcc3q$mvl$1@dough.gmane.org>

```
On 12-02-01 4:50 PM, Neal Kreitzinger wrote:
> I'm confused on why and/or how interactive rebase runs the pre-commit hook
> when doing the reword command for commit (a).
When you do a "reword" in "rebase -i", it basically does a "cherry-pick" 
of that commit first, then it does a "commit --amend". And your 
pre-commit hook should've been run during the amend.
> IOW, the pre-commit hook does not get the same results as if I were doing a
> commandline git-commit of a modified index.
Does your pre-commit hook work when doing a "commit --amend"? I'm not 
sure if you can actually modify the author (or committer) date from 
inside a pre-commit hook.

```

## Neal Kreitzinger, 2012-02-02 16:39

Subject: Re: rebase -i reword runs pre-commit hook with curious results
Message-ID: <4F2ABC5B.2030608@gmail.com>
URL: https://gitlist.dev/e/4F2ABC5B.2030608%40gmail.com
In-Reply-To: <4F2A2286.3090808@sohovfx.com>

```
On 2/1/2012 11:43 PM, Andrew Wong wrote:
> On 12-02-01 4:50 PM, Neal Kreitzinger wrote:
>> I'm confused on why and/or how interactive rebase runs the pre-commit
>> hook
>> when doing the reword command for commit (a).
> When you do a "reword" in "rebase -i", it basically does a "cherry-pick"
> of that commit first, then it does a "commit --amend". And your
> pre-commit hook should've been run during the amend.
>> IOW, the pre-commit hook does not get the same results as if I were
>> doing a
>> commandline git-commit of a modified index.
> Does your pre-commit hook work when doing a "commit --amend"? I'm not
> sure if you can actually modify the author (or committer) date from
> inside a pre-commit hook.
(We have a comment on "line 1" in our source with $User:$ $Date:$ 
keywords that the pre-commit hooks expands to insert "whoami" and "date" 
values to effect a user-datestamp at commit time.  We do this to enforce 
conflicts on same-file edits.)  Now that I understand that the 
cherry-pick takes place first to effect the transfer of the tree content 
and then a subsequent git-commit --amend of "no changes" takes place to 
effect the reword opportunity, the behavior makes sense now.  (We use 
git-commit --amend to reword commit messages also.)  The pre-commit hook 
runs prior to commit message editor just like commandline git-commit 
--amend (and plain git-commit).

thanks!

v/r,
neal

```