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 12:10:34 -0600
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <vht5qt$1qel2$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 23 Nov 2024 19:10:38 +0100 (CET)
Injection-Info: dont-email.me; posting-host="819d874cfde82265b47d769a029c49b9";
	logging-data="1915554"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX186cCRBXRB4ZGM61Rka8e8cSD9Kqqyvjtw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sbE+TYzVpIr76VqCMmqZu+pnVY4=
In-Reply-To: <vhsotb$rki$1@reader2.panix.com>
Content-Language: en-US
Bytes: 2954


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.

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