Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Craig A. Berry" Newsgroups: comp.os.vms Subject: Re: in-memory editing with EDT or EVE Date: Sat, 23 Nov 2024 14:16:31 -0600 Organization: A noiseless patient Spider Lines: 48 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 23 Nov 2024 21:16:31 +0100 (CET) Injection-Info: dont-email.me; posting-host="819d874cfde82265b47d769a029c49b9"; logging-data="1954828"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19mEfN1CvagChPuxkwlU6r9VUSYIxGHFGs=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:4geWCJ49lV/3XYECRfxlgeb7VHg= Content-Language: en-US In-Reply-To: Bytes: 3547 On 11/23/24 12:29 PM, Arne Vajhøj wrote: > 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. 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.