Re: obsolete index in wt_status_print after pre-commit hook runs

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

 



Am 15.07.2016 um 6:03 nachm. schrieb Junio C Hamano <gitster@xxxxxxxxx>:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller <andrew@xxxxxxxxxxxxxx> wrote:
>>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller <andrew@xxxxxxxxxxxxxx>:
>>> 
>>>> I pulled out the source for version 2.9.1 and briefly skimmed how run_commit and
>>>> prepare_to_commit work.  It seems that Git already understands that a pre-commit
>>>> hook can change the index, and it rereads the index before running the
>>>> prepare-commit-msg hook: https://github.com/git/git/blob/v2.9.1/builtin/commit.c#L941-L951
>>> 
>>> Quick question: Why does Git reread the index after the pre-commit hook runs?
>> 
>> Offhand I do not think of a good reason to do so; does something break
>> if you took it out?
> 
> Ahh, I misremembered.  2888605c (builtin-commit: fix partial-commit
> support, 2007-11-18) does consider the possibility that pre-commit
> may have modified the index contents after we take control back from
> that hook, so that is probably a good place to enumerate what got
> changed.  Getting the list before running the hook can give an
> out-of-date list, as you said.

Interesting.  So, the implication is that disallowing the pre-commit hook
to change the index may cause some problems (491 problems, if my run
of the tests was accurate).

Does that mean it would be desirable to update the index before the
commit message template is rendered?

Thanks,
 - Andrew Keller

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