From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: git-handler.el Date: Sat, 12 Aug 2017 12:48:22 +0200 Message-ID: <877ey9cb9l.fsf@bernoul.li> References: <87eftk9uxe.fsf@bernoul.li> <87zic7ze06.fsf_-_@detlef> <87d192aold.fsf@bernoul.li> <87o9rmiems.fsf@detlef> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1502534929 6064 195.159.176.226 (12 Aug 2017 10:48:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2017 10:48:49 +0000 (UTC) User-Agent: mu4e 0.9.19; emacs 25.2.1 Cc: Emacs developers , Dmitry Gutov To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 12:48:45 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dgTyD-0000sR-WF for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 12:48:42 +0200 Original-Received: from localhost ([::1]:43620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgTyF-00057o-Dm for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 06:48:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgTy5-00057K-Kl for emacs-devel@gnu.org; Sat, 12 Aug 2017 06:48:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgTy0-0001yf-Me for emacs-devel@gnu.org; Sat, 12 Aug 2017 06:48:33 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:53838) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dgTy0-0001wq-B7 for emacs-devel@gnu.org; Sat, 12 Aug 2017 06:48:28 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id AF2BB16693; Sat, 12 Aug 2017 12:48:23 +0200 (CEST) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id nozJVbXWBADg; Sat, 12 Aug 2017 12:48:23 +0200 (CEST) Original-Received: from desktop (77-58-214-193.dclient.hispeed.ch [77.58.214.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 3547E164B4; Sat, 12 Aug 2017 12:48:23 +0200 (CEST) In-reply-to: <87o9rmiems.fsf@detlef> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.243.197.30 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217471 Archived-At: Michael Albinus writes: > As a warmup, I have written vc-handler.el and vc-git-handler.el. They > are far from being complete, but they'll show what's possible. Great! I didn't have a change to look at this much yet, hope to get to it in a week or so. > A revisioned filename is something like "/path/to/file@@revision". > "revision" could be a revision like "81656add81", a branch like > "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax > could be changed. I would prefer /path/to/repo/@git:REVISION:path/to/file. I don't have a strong opinion about what the magic cookie should look like, but I think it should be inserted at the root of the working tree. > vc-handler.el is the common part. There is the alist > `vc-file-name-handler-alist', which lists for every magic file name > function the responsible handler function. The majority of them is also > implemented in vc-handler.el, because they don't need any vcs specific > handling. > > For every different backend, there could be a respective backend > package. I've implemented vc-git-handler.el, because I know more about > vc-git than magit. But there's no problem to implement vc-magit.el, for > example. I plan also to write at least vc-cvs.el. As I said I haven't looked at the code much yet, so I don't know what the implications of having alternative handlers for the same vc would be. But I fear that it would reduce interoperability. But packages other than VC should be able to customize the behavior to some extend and that could probably be implemented using a few hooks and *-function variables. > You might play a little bit to see how it looks like. Maybe the most > simple start is to enter dired, because it uses many of the magic file > name operations. Just do "C-x d ~/src/emacs/src/emacs.c@@" (supposed > your Emacs git is located at ~/src/emacs, as in my case). Speaking of Dired, trees (directories) should be supported in addition to blobs (files), among other things that would allow visiting them in Dired. > Both packages are far from being complete. Performance is terrible (a > proper cache mechanism is needed), In what way is performance terrible? I would have expected that asking git for information about one blob would not be that much more expensive than asking the file-system for the same information about one file. (I.e. the the difference would only become relevant if you needed information about many files.) > my git skill is restricted so I might > not use the best commands, and you will see many TODO comments. I will try to help with that, but I am a little busy right now. > It's > just a proof of concept. And I hope it is useful for both magit and vc. I am sure we can get it there. Some more thoughts: What happens when you visit say HEAD:file and then HEAD is updated? I think this should behave much the same as for files that are modified on disk. The user could then use `revert-buffer' to update the buffer. You mentioned in another message that this is read-only. While that's a good default, I think it should be possible for Magit or something else to provide a `modified-p' and a `save-file' function by setting some `*-function' variables. It would help me and others that are not very familiar with VC's internals to understand the file-handler parts if you could create one commit that implements those parts without taking advantage of any caching provided by VC and then add that caching in a separate commit. Cheers, Jonas Ps: I'll probably be unavailable for a few days.