Re: rebase -i reword runs pre-commit hook with curious results

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]