Am 04.08.2016 um 12:45 nachm. schrieb Junio C Hamano :
> Andrew Keller writes:
>
>> In summary, I think I prefer #2 from a usability point of view, however I’m
>> having
>> trouble proving that #1 is actually *bad* and should be disallowed.
>
> Yeah, I agree with your argument from the usabili
Andrew Keller writes:
> In summary, I think I prefer #2 from a usability point of view, however I’m
> having
> trouble proving that #1 is actually *bad* and should be disallowed.
Yeah, I agree with your argument from the usability and safety point
of view.
> Any thoughts? Would it be better f
Am 15.07.2016 um 6:03 nachm. schrieb Junio C Hamano :
>
> 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
Am 15.07.2016 um 6:03 nachm. schrieb Junio C Hamano :
> Junio C Hamano writes:
>> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>>
I pulled out the source for version 2.9.1 and briefly skimmed how
run_commit and
p
Am 15.07.2016 um 5:19 nachm. schrieb Junio C Hamano :
>
> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>
>>> I pulled out the source for version 2.9.1 and briefly skimmed how
>>> run_commit and
>>> prepare_to_commit work. It se
Junio C Hamano writes:
> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>
>>> 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
On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>
>> 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 ca
Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
> 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
On 15.07.2016, at 1:28 nachm., Junio C Hamano wrote:
> Earlier you said you are working on a patch series. Since you have
> already looked at the codepath already, perhaps you may want to try
> a patch series to add the missing error-return instead, if you are
> interested?
Definitely intereste
Andrew Keller writes:
> On 15.07.2016, at 1:02 nachm., Junio C Hamano wrote:
>
>> Expected outcome is an error saying "do not modify the index inside
>> pre-commit hook", and a rejection. It was meant as a verification
>> mechansim (hence it can be bypassed with --no-verify), not as a way
>> to
On 15.07.2016, at 1:02 nachm., Junio C Hamano wrote:
> Expected outcome is an error saying "do not modify the index inside
> pre-commit hook", and a rejection. It was meant as a verification
> mechansim (hence it can be bypassed with --no-verify), not as a way
> to make changes that the user did
Andrew Keller writes:
> I have observed an interesting scenario. Here are example reproduction steps:
>
> 1. new repository
> 2. create new pre-commit hook that invokes `git mv one two`
> 3. touch one
> 4. git add one
> 5. git commit
>
> Expected outcome: In the commit message template, I expect
12 matches
Mail list logo