| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:30:04 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,541 |
| Posted today: | 6 |
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
On 11/22/24 8:02 PM, Lawrence D'Oliveiro wrote:
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.
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.
You’re thinking of older-style VCSes like Subversion, which did indeed
have a client/server architecture. It was various problems with those that led to the creation of Git.
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.
On 11/23/2024 3:16 PM, Craig A. Berry wrote:
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?
If somebody have a program that need to allow user to
edit data and the program is VMS specific and the target
editors are EDT and TPU, then maybe doing the edit in
memory makes sense.
You can still argue that both subprocess with external editor
and temp file or simple callable editor editor with temp file is
simpler code wise using just the VMS provided API's and
not some wrapper found on the internet.
But I like multiple options.
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?
On 11/23/24 6:53 PM, Arne Vajhøj wrote:
On 11/23/2024 3:16 PM, Craig A. Berry wrote:
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?
As I tried to explain before, a git commit consists of the metadata
(author, timestamp, etc.), the commit message, the branch, and the
actual diff content of the changeset. All of the other pieces are
stored on-disk, so it's hard to see a reason to keep the commit message
in memory when it needs to be combined with the other pieces in order to produce the commit.
It should also be mentioned that the editor used for editing commit
messages is configurable, so git's process for producing a commit needs
to work with any and every editor.
What problem are you trying to solve by keeping a kilobyte or three in
memory instead of persisting it to disk where any and every utility in
the toolbox can operate on it?
Doing in memory editing is not quite as basic. But it is possible.
With EDT and TPU on VMS.
And using a normal shareable image and ctypes, then it also works in
Python:
On 11/23/2024 10:35 PM, Arne Vajhøj wrote:
If somebody have a program that need to allow user to
edit data and the program is VMS specific and the target
editors are EDT and TPU, then maybe doing the edit in
memory makes sense.
You can still argue that both subprocess with external editor
and temp file or simple callable editor editor with temp file is
simpler code wise using just the VMS provided API's and
not some wrapper found on the internet.
But I like multiple options.
I just created a JNI wrapper around the callable
editor wrappers.
So now the Groovy snippets:
res = Edit.edt("A\nBB\nCCC")
print(res)
and:
res = Edit.tpu("A\nBB\nCCC")
print(res)
work.
On Sun, 24 Nov 2024 19:27:35 -0500, Arne Vajhøj wrote:
And using a normal shareable image and ctypes, then it also works in
Python:
Soon as you mentioned “ctypes”, I had to have a look. ;)
I’m not a fan of wildcard imports. I know you tend to need a lot of stuff from ctypes, but I prefer to do
import ctypes as ct
so you can then write
memedit.memedt.argtypes = [ct.c_char_p, ct.c_char_p, ct.c_int]
memedit.memedt.restype = ct.c_int
etc.
But this is what a source control system really should be using for such functionality. No need for temporary disk files.