Re: in-memory editing with EDT or EVE

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.