From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: git-handler.el Date: Sat, 12 Aug 2017 20:43:50 +0300 Message-ID: <83h8xcisvd.fsf@gnu.org> References: <87eftk9uxe.fsf@bernoul.li> <87zic7ze06.fsf_-_@detlef> <87d192aold.fsf@bernoul.li> <87o9rmiems.fsf@detlef> <877ey9cb9l.fsf@bernoul.li> <83y3qphu4s.fsf@gnu.org> <87a834d7ew.fsf@bernoul.li> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1502559911 16142 195.159.176.226 (12 Aug 2017 17:45:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2017 17:45:11 +0000 (UTC) Cc: dgutov@yandex.ru, michael.albinus@gmx.de, emacs-devel@gnu.org To: Jonas Bernoulli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 19:45:07 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 1dgaTC-0003tN-3n for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 19:45:06 +0200 Original-Received: from localhost ([::1]:43908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgaTI-0002lG-5J for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 13:45:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgaSe-0002ko-BH for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:44:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgaSa-0003Mi-Du for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:44:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgaSO-0003ER-BR; Sat, 12 Aug 2017 13:44:16 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2529 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dgaSL-0006wA-Or; Sat, 12 Aug 2017 13:44:16 -0400 In-reply-to: <87a834d7ew.fsf@bernoul.li> (message from Jonas Bernoulli on Sat, 12 Aug 2017 19:26:15 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:217489 Archived-At: > From: Jonas Bernoulli > Cc: michael.albinus@gmx.de, emacs-devel@gnu.org, dgutov@yandex.ru > Date: Sat, 12 Aug 2017 19:26:15 +0200 > > >> > 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: > > /path/to/dir-containing-closest-control-file/@: > > instead of > > /path/to/dir-containing-closest-control-file/@/ > > when trying to stay as close the internals of that ? Well, for starters, it will defeat the completion machinery, or at least make it much more complicated. > Also isn't that an implementation detail and users of still > think of "/path/to/top" as "the repository"? If that is so then > what should it matter that spreads the history files across > the repository instead of putting them into a dedicated control > directory? FILE@@revision is not a history file, it is FILE as it looked like at given VERSION. Where that information is kept is beside the point. As I'm sure you understand, so I guess I don't really see the point you are making here. > > Michael's scheme does support such VCSes. For a > > VCS like Git or Bazaar, Michael's scheme shouldn't get in the way, I > > think. > > Maybe we could use different schemes for different vc systems. That would be undesirable, I think. > The revision is part of a virtual directory structure Sorry, you lost me. What is that "virtual directory structure", and how is it relevant to this issue? > This is one way of accessing as stored in : We are talking about abstractions, not about their Git implementation. So why do we have to consider blobs? > 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 > same revision/tree". I guess I'm so Git-ignorant that I don't even understand what that means. Maybe I shouldn't be part of this discussion.