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 19:26:15 +0200 Message-ID: <87a834d7ew.fsf@bernoul.li> References: <87eftk9uxe.fsf@bernoul.li> <87zic7ze06.fsf_-_@detlef> <87d192aold.fsf@bernoul.li> <87o9rmiems.fsf@detlef> <877ey9cb9l.fsf@bernoul.li> <83y3qphu4s.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1502558795 8323 195.159.176.226 (12 Aug 2017 17:26:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2017 17:26:35 +0000 (UTC) User-Agent: mu4e 0.9.19; emacs 25.2.1 Cc: dgutov@yandex.ru, michael.albinus@gmx.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 19:26:29 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 1dgaB9-0001hB-CF for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 19:26:27 +0200 Original-Received: from localhost ([::1]:42610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgaBF-0004PA-Rk for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 13:26:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgaB8-0004OM-41 for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:26:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgaB6-00049Z-K8 for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:26:26 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:48060) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dgaB2-00048e-JO; Sat, 12 Aug 2017 13:26:20 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id D842A16559; Sat, 12 Aug 2017 19:26:16 +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 o4lwHZjViBmA; Sat, 12 Aug 2017 19:26:16 +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 4A00816305; Sat, 12 Aug 2017 19:26:16 +0200 (CEST) In-reply-to: <83y3qphu4s.fsf@gnu.org> 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:217487 Archived-At: Eli Zaretskii writes: >> From: Jonas Bernoulli >> Date: Sat, 12 Aug 2017 12:48:22 +0200 >> Cc: Emacs developers , Dmitry Gutov >> >> > 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 ? 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? Using such a and given: /path/to/top/ |- fileA |- .fileA.history `- subdir/ |- fileB `- .fileB.history I don't know whether its users would prefer A1) /path/to/top/@:/ A2) /path/to/top/@// or B1) /path/to/top/subdir/@: B2) /path/to/top/subdir/@/ But even if to users of (B) is preferable to (A), I don't see how (B2) is superior to (B1), or how (B1) is even incompatible. But I never used such a vcs, so probably I am missing something. > 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. > If you disagree, please show some use cases where this could > cause trouble. I care more about the conceptual consistency than use cases at this point, because I think that even if we cannot think of any concrete issues now, we are sure to eventually run into. The revision is part of a virtual directory structure and it should appear in the correct (i.e. hierarchic) place. People have come to expect a hierarchic structure when dealing with files, and if we break that consistency (just for compatibility with legacy vc systems), then that will cause confusion. This is one way of accessing as stored in : cd /tmp/repo git worktree add ../repo_ find-file /tmp/repo_/ And with a file handler instead of a worktree checkout: cd /tmp/repo find-file /tmp/repo/git@: or find-file /tmp/repo/@@/