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:34:05 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vhte7t$gp9$1@reader2.panix.com>
References: <vhr9ct$1dilp$1@dont-email.me> <vhsm4i$1nfvc$1@dont-email.me> <vhsotb$rki$1@reader2.panix.com> <vht5qt$1qel2$1@dont-email.me>
Injection-Date: Sat, 23 Nov 2024 20:34:05 -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: 3276
Lines: 49

In article <vht5qt$1qel2$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
>On 11/23/24 8:30 AM, Dan Cross wrote:
>> In article <vhsm4i$1nfvc$1@dont-email.me>,
>> Craig A. Berry <craigberry@nospam.mac.com> wrote:
>>> On 11/22/24 8:02 PM, Lawrence D'Oliveiro 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.  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?  Plus
>debugging and recovery from failed operations would surely be much
>easier with some kind of persistence of intermediate steps.  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.

It does seem like this is solving a non-problem.  The approach
is mildly interesting, though, and vaguely reminds me of how
VM/CMS used addressability to the text editor to build all sorts
of useful interfaces.  It's not exact, of course, but the idea
of an in-memory, editor-centric interface is not far off.

>>>> On Linux systems at least, temporary files are usually created in /tmp,
>>>> and distros commonly mount an instance of tmpfs on that, so no actual disk
>>>> files need be created.
>>>
>>> But that is not what git does when staging a commit.
>> 
>> Regardless of that, it is what git does when composing a commit
>> message.
>
>I simply meant staging in the sense of preparing, not staging in the
>git-specific sense of adding to the index (which happens before the
>commit operation), so you've made a distinction without a meaningful
>difference. I was simply trying to make clear that Lawrence's comments
>about /tmp and tmpfs have nothing to do with the matter at hand.  At
>least by default the commit messge goes in .git/COMMIT_EDITMSG in the
>current repository, so /tmp and how it's implemented are irrelevant.

Except that the editor likely creates a temporary file in /tmp,
but kind of see what you're saying.

	- Dan C.