Re: git-handler.el

[Jonas Bernoulli]

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
> 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.