[Info-vax] in-memory editing with EDT or EVE

[Arne Vajhøj]

On 11/23/2024 3:16 PM, Craig A. Berry wrote:
> On 11/23/24 12:29 PM, Arne Vajhøj wrote:
>> On 11/23/2024 1:10 PM, Craig A. Berry wrote:
>>>                                    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.

OK. I am still thinking SVNish. Sorry.

But does it matter?

edit disk file--read disk file--write to local repo
vs
edit in memory--write to local repo

still seem like a difference to me.

Or is git external editor actual editing the final file
inside the repo?

Arne