Re: git-handler.el

[Eli Zaretskii]

> From: Jonas Bernoulli <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Sat, 12 Aug 2017 19:26:15 +0200
> 
> >> > 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.
> >
> > That doesn't scale to VCSes which keep separate versions for
> > individual files.
> 
> How so?  Wouldn't my scheme just look like:
> 
>   /path/to/dir-containing-closest-control-file/<vcs>@<rev>:<file>
> 
> instead of
> 
>   /path/to/dir-containing-closest-control-file/<vcs>@<file>/<rev>
> 
> when trying to stay as close the internals of that <vcs>?

Well, for starters, it will defeat the completion machinery, or at
least make it much more complicated.

> Also isn't that an implementation detail and users of <vcs> still
> think of "/path/to/top" as "the repository"?  If that is so then
> what should it matter that <vcs> spreads the history files across
> the repository instead of putting them into a dedicated control
> directory?

FILE@@revision is not a history file, it is FILE as it looked like at
given VERSION.  Where that information is kept is beside the point.
As I'm sure you understand, so I guess I don't really see the point
you are making here.

> > Michael's scheme does support such VCSes.  For a
> > VCS like Git or Bazaar, Michael's scheme shouldn't get in the way, I
> > think.
> 
> Maybe we could use different schemes for different vc systems.

That would be undesirable, I think.

> The revision is part of a virtual directory structure

Sorry, you lost me.  What is that "virtual directory structure", and
how is it relevant to this issue?

> This is one way of accessing <blob> as stored in <branch>:

We are talking about abstractions, not about their Git implementation.
So why do we have to consider blobs?

> One example use case where the scheme that I propose would be nicer than
> the non-hierarchic one is "using find-file to open another blob from the
> same revision/tree".

I guess I'm so Git-ignorant that I don't even understand what that
means.  Maybe I shouldn't be part of this discussion.