Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.vms
Subject: Re: in-memory editing with EDT or EVE
Date: Sat, 23 Nov 2024 20:35:39 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vhtear$gp9$2@reader2.panix.com>
References: <vhr9ct$1dilp$1@dont-email.me> <vhsotb$rki$1@reader2.panix.com> <vht5qt$1qel2$1@dont-email.me> <vht6v1$1qfvl$1@dont-email.me>
Injection-Date: Sat, 23 Nov 2024 20:35:39 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="17193"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 2920
Lines: 49

In article <vht6v1$1qfvl$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 11/23/2024 1:10 PM, Craig A. Berry wrote:
>>>>> On Fri, 22 Nov 2024 19:59:07 -0500, Arne Vajhøj wrote:
>>>>>> But this is what a source control system really should be using for 
>>>>>> such
>>>>>> functionality. No need for temporary disk files.
>> 
>> "should" seems awfully strong there and I don't understand why temporary
>> disk files pose a problem.
>
>It is likely not a problem with any measurable impact.
>
>But for the task as hand - having the user write a
>commit message that is to be send to a server over the
>network - then the use of a temporary files seems like
>an unnecessary detour to me.

That's not really how git works.  Git puts the entire commit
into the _local_ repository, which one can then push to a
remote.

>>                                    To compute the commit ID, git has to
>> calculate the SHA1 of the actual content changes, the metadata (who,
>> when, etc.), and the commit message. While that could theoretically all
>> be done in memory, how can be you sure it would all fit in memory?
>
>The files being committed are on disk, so Git will be doing disk IO.
>
>But I don't see that as an argument for that the commit message need to
>pass through a file.
>
>>                                                             Plus
>> debugging and recovery from failed operations would surely be much
>> easier with some kind of persistence of intermediate steps.
>
>Maybe. But It is not obvious to me that having commit message
>on disk in a temporary file will help troubleshooting.
>
>>                                                           So I think
>> the actual design of git is much better than this hypothetical one that
>> tries to avoid saving anything to disk until the last step.
>
>The commit message should not be saved on disk client side at all.
>The message get created and get sent to the server over the network.

That's just not how git works.

	- Dan C.