Re: git protocol for Tramp

Peter Marinov <[email protected]> writes:

Hi Peter,

> Would you please try it in this format:
>
> $ emacs -nw -l ~/work/git-tramp/git-tramp.el /git:HEAD:/home/peterm/tmp/emacs

That works for me, thanks. Since this is WIP, there are still some
deficiencies:

- (find-file "/git:HEAD:/home/albinus/src/emacs/lisp/net/") does not work.
- File name completion is missing (important for large repositories)

aso. Just after playing with it for a minute or so. And no, no blame, I
know it is the development state.

>> > My ultimate plan is for this to be integrated with
>> > 'vc-print-root-log'. Where now we can do '=' to see a diff, or RET to
>> > see the commit comment, I would like to add 't' to invoke git-tramp
>> > over that hash in the log.
>>
>> Well, I'm not sure whether it is what users need this way. I would
>> rather expect a syntax which gives first the file name, and after that
>> the git hash. This is more convenient when you want to compare different
>> versions of the same file.
>
> There is a problem with the order where the hash is after the
> path. Let me explain:
>
> In the current format we have (with some a location deeper in the repo):
>
> /git:5e7a71d:/home/peterm/tmp/emacs/doc/lispintro
>
> Apart from the protocol and the hash we have path. That path itself
> has 2 components:
>
> '/home/peterm/tmp/' -- this is a path to a repo that has nothing to do
> with the protocol and the hash
>
> 'emacs/doc/lispintro' -- this is a path inside the repo
>
> Notice that the path inside the repo needs the hash, that is because
> the path inside the repo exists, or not, depending on the history of
> the repo, we can't do 'TAB' to autocomplete paths inside a repo
> without the corresponding hash.
>
> The hash has to precede the file path!

Users think in terms of a file name first. The hash is second level
thought.

But of course, it depends on the use case you have in mind.

>> Some years ago, I wrote something similar called 'vc-handler'. The idea
>> was to support a file name syntax like
>> "/path/to/file@@/branch/revision-or-label". You see that the resivision
>> (hash in the git case) and the branch come after the file name.
>> The package 'vc-git-handler' was the backend for git; I didn't implement
>> it for other VCS backends.
>
> Thank you for sending me your implemention on this topic, I'm going to
> study it and borrow ideas.

You're welcome :-) I gave it up due to the inherent problems (bad
performance for completion of hashes in large repositories, bad context
for the hash identifiers).

>
>> Well, it worked to some extend. But I gave up, because the performance
>> was miserable, and I'm not such a git aficionado that I could tune it.
>
> I think the performance problems might be in only 1 place:
> autocompletion of hashes/branches/tags. To autocomplete you will always
> need the complete list, imagine the length of one such list on an old
> project such as Emacs, or Linux kernel.

Exactly.

> For the moment I chose not to autocomplete.

Well, perhaps not for the hashes. But I believe it is mandatory for the
file names.

>> --8<---------------cut here---------------start------------->8---
>> # emacs -Q -L ~/lisp -l vc-handler ;; My private Lisp files reside in ~/lisp
>> C-x C-f ~/src/git-tramp/ ;; This is your checked out repo
>> C-x C-f git-t TAB ;; Expands to ~/src/git-tramp/git-tramp.el
>> @@/ TAB ;; Expands to { HEAD | master/ }
>> mas TAB ;; Expands to { 07db2bd | 1196543 | 2b9edd5 | ... }
>> 07db2bd RET ;; Here we are.
>> --8<---------------cut here---------------end--------------->8---
>>
>> 8 years old; I'm pretty sure there are missing parts.
>
> In your example, once you are past the path ~/src/git-tramp, you can't
> continue with the completion if you don't already have the hash (or
> equivalent) in the path.

Side remark: I've stolen the format from ClearCase. In ClearCase,
directories are also revisioned objects. So you could use a file name
like "~/src/git-tramp@@/<rev1>/git-tramp.el/<rev2>". Git doesn't support
revisioned directories, one would need to simulate them. Nothing I would
implement now.

> From my point of view, the TRAMP's path format solves for this
> requirement.

Sure, I don't want to stop you. I just wanted to mention the problems I
see with your approach.

> Regards,
> Peter M.

Best regards, Michael.