Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Craig A. Berry" <craigberry@nospam.mac.com>
Newsgroups: comp.os.vms
Subject: Re: in-memory editing with EDT or EVE
Date: Sat, 23 Nov 2024 14:16:31 -0600
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <vhtd6v$1rl0c$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> <vht6v1$1qfvl$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 21:16:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="819d874cfde82265b47d769a029c49b9";
	logging-data="1954828"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19mEfN1CvagChPuxkwlU6r9VUSYIxGHFGs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4geWCJ49lV/3XYECRfxlgeb7VHg=
Content-Language: en-US
In-Reply-To: <vht6v1$1qfvl$1@dont-email.me>
Bytes: 3547


On 11/23/24 12:29 PM, Arne Vajhøj 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.
> 
>>                                    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.

There is no "client."  In a DVCS like git, when you commit a change,
everything is written locally.  Pushing to a server is an optional
separate operation and what you push is the version history that has
been written locally first.  There is never a point where the commit
message is sent over the network to another machine before being stored
as one component of a commit.