From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: git-handler.el Date: Sat, 12 Aug 2017 21:52:35 +0200 Message-ID: <878tiod0n0.fsf@bernoul.li> References: <87eftk9uxe.fsf@bernoul.li> <87zic7ze06.fsf_-_@detlef> <87d192aold.fsf@bernoul.li> <87o9rmiems.fsf@detlef> <877ey9cb9l.fsf@bernoul.li> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1502567611 992 195.159.176.226 (12 Aug 2017 19:53:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2017 19:53:31 +0000 (UTC) User-Agent: mu4e 0.9.19; emacs 25.2.1 Cc: Dmitry Gutov , Michael Albinus , Emacs developers To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 21:53:24 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dgcTK-00086x-EK for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 21:53:22 +0200 Original-Received: from localhost ([::1]:49195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgcTP-0006fO-6a for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 15:53:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgcSh-0006f8-El for emacs-devel@gnu.org; Sat, 12 Aug 2017 15:52:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgcSc-000064-I8 for emacs-devel@gnu.org; Sat, 12 Aug 2017 15:52:43 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:54152) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dgcSc-000050-87 for emacs-devel@gnu.org; Sat, 12 Aug 2017 15:52:38 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 2DC6116559; Sat, 12 Aug 2017 21:52:36 +0200 (CEST) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id Gs9UDxL-lKmn; Sat, 12 Aug 2017 21:52:35 +0200 (CEST) Original-Received: from desktop (77-58-214-193.dclient.hispeed.ch [77.58.214.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 9093A16305; Sat, 12 Aug 2017 21:52:35 +0200 (CEST) In-reply-to: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.243.197.30 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217498 Archived-At: John Wiegley writes: >>>>>> "JB" == Jonas Bernoulli 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 " n" and " 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.