Re: git-handler.el

[Jonas Bernoulli <jonas@bernoul.li>]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "JB" == Jonas Bernoulli <jonas@bernoul.li> writes:
>
> JB> I would prefer /path/to/repo/@git:REVISION:path/to/file. I don't have a
> JB> strong opinion about what the magic cookie should look like, but I think
> JB> it should be inserted at the root of the working tree.
>
> I would prefer having both: sometimes I want to "browse into the Git tree at a
> revision", and sometimes I'm already in a deep directory within a project, and
> I want to think in terms of "browse into the many past versions of a given
> file". Both make sense from different points of views.

Yes of course.  Unfortunately we cannot have both without making an
additional effort. (*)

When using the REV:PATH scheme "another file from the same revision"
works exactly the same as "another file from the same directory", but
even when using the PATH:REV scheme the "same file, another revision"
use-case only (loosely) corresponds to an operation on regular files:
"same file, from this other revision whose human readable name I know".

So if you are visiting "/path/to/@@file/some-feature", it would be nice
if `find-file' gave you "Find file: /path/to/@@file/" and you could type
"ma TAB RET" to visit "/path/to/@@file/master".  But that's only one
variant of "same file, another revision" and probably not even the most
common one.

Another variant would be "same file, next/previous revision" where
next/previous could have different meanings.  A common one is "the
next/previous revision which touched this line".  Currently there's even
exists a package just for that use case: `git-timemachine'.

(Magit also provides that same feature but the implementations are not
compatible.  `git-timemachine' reuses the same buffer to visit different
version of the file (which has the benefit that no buffers have to be
cleaned up later), while Magit uses a new buffer (which allows you to
look at different versions of the same file at once).)

Anyway, I don't think it makes sense to teach `find-file' about going to
the next/previous revision.  Instead that use-case should be handled by
separate commands, which would likely be bound to "<some-prefix> n" and
"<some-prefix> p" (that's what `git-timemachine' and Magit currently do).

The point I am trying to make here is that `find-file' cannot possibly
the right command to handle all cases of "same file, another revision"
with ease, while it is completely suitable for "same revision, another
revision", with no extra effort.  But only if we go with the REV:PATH
scheme.

(*) If we go with the REV:FILE scheme then I propose that we make the
    "same file, another *named* revision" use-case easy by adding a
    separate command just for that.  The user would be presented with
    "Find revision of file /path/to/: ".  And if the user already
    invoked `find-file' or a variant thereof, then there should be
    a key binding to abort that and switch to the "change revision"
    command instead.