[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 12 Aug 2017 12:48:22 +0200
mu4e 0.9.19; emacs 25.2.1
Michael Albinus <address@hidden> 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
> 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
> 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
> 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.
> 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
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.
Ps: I'll probably be unavailable for a few days.