[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 12 Aug 2017 19:26:15 +0200
mu4e 0.9.19; emacs 25.2.1
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:
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
Using such a <vcs> and given:
I don't know whether its users would prefer
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
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>:
git worktree add ../repo_<branch> <branch>
And with a file handler instead of a worktree checkout:
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