Re: git-handler.el

[Jonas Bernoulli]

Eli Zaretskii <address@hidden> writes:

>> From: Jonas Bernoulli <address@hidden>
>> Date: Sat, 12 Aug 2017 12:48:22 +0200
>> Cc: Emacs developers <address@hidden>, Dmitry Gutov <address@hidden>
>>
>> > 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>?

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?

Using such a <vcs> and given:

  /path/to/top/
  |- fileA
  |- .fileA.history
  `- subdir/
     |- fileB
     `- .fileB.history

I don't know whether its users would prefer

  A1) /path/to/top/<vcs>@<rev>:<subdir>/<fileB>
  A2) /path/to/top/<vcs>@<subdir>/<fileB>/<rev>

or

  B1) /path/to/top/subdir/<vcs>@<rev>:<fileB>
  B2) /path/to/top/subdir/<vcs>@<fileB>/<rev>

But even if to users of <vcs> (B) is preferable to (A), I don't see
how (B2) is superior to (B1), or how (B1) is even incompatible.

But I never used such a vcs, so probably I am missing something.

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

> If you disagree, please show some use cases where this could
> cause trouble.

I care more about the conceptual consistency than use cases at this
point, because I think that even if we cannot think of any concrete
issues now, we are sure to eventually run into.

The revision is part of a virtual directory structure and it should
appear in the correct (i.e. hierarchic) place.  People have come to
expect a hierarchic structure when dealing with files, and if we break
that consistency (just for compatibility with legacy vc systems), then
that will cause confusion.

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

  cd /tmp/repo
  git worktree add ../repo_<branch> <branch>
  find-file /tmp/repo_<branch>/<blob>

And with a file handler instead of a worktree checkout:

  cd /tmp/repo
  find-file /tmp/repo/git@<branch>:<blob>
    or
  find-file /tmp/repo/@@<blob>/<branch

Clearly only the scheme I suggested is consistent with the expectation
of a hierarchic directory structure.

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