Peter Marinov <[email protected]> writes: > Michael,
Hi Peter, > * I've used ClearCase for a long period during my career, I like your > specific suggestion above. > > I imagine that one 'rev' the path should be sufficient, it could > be a hash or a tag or a branch name. > > The complete format will be: > > ~/path/to/repo@@rev/path/to/file/or/dir > > And it will open a dired or file (in r/o mode) Yes. And it will support all other Emacs functions over files out-of-the-box, think about diff/ediff and whatsoever. > * I thought about speed of autocompletion of 'rev', the autocompletion > of hashes has to happen at a low-level implementation. > > Instead of obtaining all hashes via 'git log', go straight to the > folder '.git/objects'. Notice that the hashes are broken in a > two-level directory tree. This is what gives the speed of git itself > to de-reference quickly object by their hashes. Doing autocompletion > based on this directory structure should be fast. Right. I'm not a git guru, and my code was just a proof-of-concept. Many optimizations will be possible. > Nonetheless, it might turn out that autocompletion of hashes doesn't > make sense, most likely users will copy & paste that part (when not > using tags/branches/etc.) Exactly. What I was thinking about is adding a help-echo property to every hash string in Emacs, which shows the commit header line. It would be much fun, but likely too slow. Unfortunately. Autocompletion over commit messages, authors, commit dates (or ranges of them) would also be much fun. Everything for the far future. > I will most likely borrow some ideas (with appropriate attribution) > from your implementations, I see that you have worked on some corner > cases which I hadn't implemented in my first/early implementation. Take whatever you want! I have no plan to polish the code for public release; as said it was just a proof of concept. If you have questions or need further support for file name handler machinery: I'm your man. However, I'm not sure we shall continue to discuss in the tramp-devel ML. It isn't a Tramp issue; I guess we could discuss privately. Or, if you plan to publish your code later as ELPA package, you might write an Emacs bug report (which will be handled as wishlist). Then we can discuss there everything with public audience. > Best regards, > Peter M. > https://hangar118.sdf.org Best regards, Michael.
