Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: in-memory editing with EDT or EVE
Date: Sat, 23 Nov 2024 13:29:55 -0500
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <vht6v1$1qfvl$1@dont-email.me>
References: <vhr9ct$1dilp$1@dont-email.me> <vhrd3u$1dqca$3@dont-email.me>
 <vhsm4i$1nfvc$1@dont-email.me> <vhsotb$rki$1@reader2.panix.com>
 <vht5qt$1qel2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 23 Nov 2024 19:29:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f68b85c9bcbd69707476b96356350f37";
	logging-data="1916917"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/arG4Oase372wci4Wdc+QvxoaV7KIdQyU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cB206h+DFKSiEwtRnkElpaOe8RM=
Content-Language: en-US
In-Reply-To: <vht5qt$1qel2$1@dont-email.me>
Bytes: 2897

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.

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

Arne