From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.bugs Subject: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Tue, 28 Feb 2023 01:34:23 +0100 Message-ID: References: <5dea8e3b-4867-52f8-19fb-9bf5ab167f46@yandex.ru> <66ce5a8f-5321-47b2-b605-38a6aea19190@yandex.ru> <59fa389f-d954-8f5b-6378-fc28a60e98aa@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15111"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 61817@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 28 01:35:23 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWnxh-0003dL-NH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Feb 2023 01:35:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pWnxP-0005He-EP; Mon, 27 Feb 2023 19:35:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pWnxO-0005Gh-EZ for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 19:35:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pWnxO-0000v1-4h for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 19:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pWnxN-0006O6-Vn for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 19:35:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Arthur Miller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Feb 2023 00:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61817 X-GNU-PR-Package: emacs Original-Received: via spool by 61817-submit@debbugs.gnu.org id=B61817.167754447924512 (code B ref 61817); Tue, 28 Feb 2023 00:35:01 +0000 Original-Received: (at 61817) by debbugs.gnu.org; 28 Feb 2023 00:34:39 +0000 Original-Received: from localhost ([127.0.0.1]:49279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWnx0-0006NH-Ai for submit@debbugs.gnu.org; Mon, 27 Feb 2023 19:34:39 -0500 Original-Received: from mail-vi1eur05olkn2015.outbound.protection.outlook.com ([40.92.90.15]:34272 helo=EUR05-VI1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWnwv-0006Mn-Eb for 61817@debbugs.gnu.org; Mon, 27 Feb 2023 19:34:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i+ewHxyNuHyesYkii6QEpAQivID1mojU8sPBxyS+jjhZ3N8Oa+sggZHy2j1ibGInVR094dTda/wVdJLCORUN1AswLavRsGKxgmNYicu1fUwnNvPvuXzzjea1j3vUOGhJ3bX0ncvmmM3GnD8IV9xqp9cElDhukFgNrOxzqfmAiCGpwZsKnvz6WlmSbprMIqK/M7U2kiSGl9Atr9DXuDxEZi1EShYn3WwmbM93CPnpTa7jq45mZF6TOfJQhyuhe4McMB5qnyD4S3QAJm8QU5ISGNT5dxUXMg3+/c/fc9orSRbFmuqGY3oMFtnsBtXjaVcTuC0VilYW6VAqsLEvPjXdAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5Op6J4psFyq53/r8PJSX+QS3uQPs78JK9o+xNvL4zEQ=; b=elv0u0TlHQNnk/O0Q/p8CARuCrdAnF2UCJh1WtdcsRF9AU7vzuvRAMVW0tlPaCNezQ/Iu2xx8Km1fvQlBWTQwDG91UNz2041j3F9zDBLxFStGyBS/2hnqXmVBHEkRLbkd9K+M4jNPUCgXQIjPy+ew9cvpGBobYip691NtxEiOcfVHFsxhyOCcH6we2l1ZO0QO5Ka0oK2QJ5oD2AsCx0VPYflauxuirtwBi/qYIPeYsfXB7SDjZr4Mv+abToxDwsCFIOl01aPMyapzICxR1+evIPivKDzQ6m/LQu25UgGsRq7EgcFg4CGMV/XVSd1NCKyz+8WjmPXFs5b7sDX7mHsEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Op6J4psFyq53/r8PJSX+QS3uQPs78JK9o+xNvL4zEQ=; b=PW7nS8r6ZB5NYPXiY+Dp+UAz4/gocYIv4+Vm5nzdr1c9f7wUtZX71HVoZWFKjb+mIy6hGl+Uj186y0AsQgWmUMLMn3m08UUquQMrUZfqaWAG557DZXCvi7wL4ohI+w7bE2DTZ00eXB7J06ZD8x0ETXOEFjy8H1QVZNdzXknqArXrML+NVq/EsxblqjuQdoDDCEfOe3QBJjgNIzeGnyBK10ipl5k4mSeV3Ke2/YCTtVg7scYgDvG8jrxRiEaz4NSuY5cVlYQRIY+ol1SdrmFal1hzMSrIlLscvN0tYJVS7tO7qzfBGtxzJynOYtatgnOBbgPubLF/HKJJGaQT4fFM2Q== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by DB8PR09MB3593.eurprd09.prod.outlook.com (2603:10a6:10:f8::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.27; Tue, 28 Feb 2023 00:34:26 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::f2af:9752:58df:ad9]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::f2af:9752:58df:ad9%8]) with mapi id 15.20.6134.030; Tue, 28 Feb 2023 00:34:26 +0000 In-Reply-To: <59fa389f-d954-8f5b-6378-fc28a60e98aa@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Feb 2023 00:39:48 +0200") X-TMN: [wwQ1UUdd4U0PMsPwkD2evAVyDrXrKL9s] X-ClientProxiedBy: FR3P281CA0063.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:4b::13) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87r0uahblc.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|DB8PR09MB3593:EE_ X-MS-Office365-Filtering-Correlation-Id: f8170843-4a04-4a9e-e31c-08db19238af3 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xyxMF3JAEBfRhhIWf9IvOAKTdC+rn8DcD7X4ZccMYJvdjeFY90JVXf+AUVLFmTYKwlYLJjF6tj7Pr8ixeHDYIaZ1392pbdxUarFXK39eimcFPK28AMSVxz7aj+jJfhNF2LspO+ok3+BYWSS2tE2JdF+9P3gVk0utm+qNVA9fpMRSRK4Gna6QZow7xkEDfQP7ZBMbw4WC7ggk0xBeo/lni6VRNpsUDQ0eg5blb2mLui2HsLpnynWYL8O59mHy3PAMZGStJtnGb+pky8hnpjav2ybGWiy7Kp7VBcspcc+KaOoIIzIZln6uq0ajr/zmkjDJ9BPCRd7N6hqO26vrkuRzX6LR+eyQBl+r/hXcL6Reyr055d+bQN7nU2xE5gdd4jwtR/1VVOKEA67HOIMJ9UgcodWObW6Q541pQlPKpzNknsKwIH6Xc8zlpjrI8NA01ZqS7QSUBgXHLOsgnNN8TsF+TBl/K76XBz52KePNLOJZ0dHzwYBskJfa+icfnXGFcyyhr3WogiuUyiLLnU496rwcfmLdmEgTmEAgWNfcCY/TDYIOAz6LQ5yaNrf0NI7iPLW4ScgDVIhrPLtcMEvEs+96qhZfOtSPg54dZxw/pgMpifgRwvu+BCzsmhu9mZkUJkNKJFhHl+bnTHDTU+BsXpJpP62HR0+OkzGCMkBs1flh+Uw= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: RDFArIK4jTJIjemG4J2SPH8PjWwRvKxpSBRPysJjuDU4PpNp8dAD/px60bSXYrm5B2GW6qpLwfWbe/Fm/FjMQ4QUbMeHFrf+pf2V19eLIP+/8WQaTdMqzuubsQcxM1D/KeRzgNQkmZBeU3qQ58qt5hiieb1gh9XJ51xLpyA/I76KqlRaem7W9iZh5E7X1W+iMIJshaF6GXQYUgZfKRX4v3t3HrRiLRBEIQbYa2NyQq1pn0PFnRhojMGsphtU8FjGmSdN1075KWhz7khGLlnWaB1c2LtZiLZnnxdqXDYJkoFtPsv08vXJzbTgGIM2ILXxLYksPiW7XDC1zr+9Ca7SBKuDQq2N1qddWTvEPAYhSOQtPK3N3t35m9dO6Ra0ZLzufNiV8AmYUas7sREbmpvxjkrm4DA/QV8GrTW+PwY6dKu6QxIRV3496qUZhsfsneNVQVnBTzHv6iLeFw6b4tDjPSNaqfviT7la7oy/1WjT87KGBFKH6FrTMf8gPMkzxcwMKNP0XiZ0d6fCWXmsCcw6D6Ytyp3peWKnsV42+1dp21N2O3uFfreLgD5O2jpWSI/hwwNI3ylamujli355zfe9dFXuKa6QYzDMJ5EQSsksEVAExEMxoMllNknilnQshFxZXuDLRsF8SQd+xoIXMje6C9j8AARhpiDZJ9IzCH42QY5UW0zZJ0gXeQvZkWHHU3HrvvHyxbInR6iFkuBoVLu4SkpQQ/WGr90sECI9OsK0FcZjzOm7xhnF5uZeDY QDJa9u5nlny8umQ/q9+uqvgWB60fLhpZX1wM14zIOp406c9K/GyNjbnZIjdREDKlqxlrBOhsAlnQciQNGtTsoufIsVOONw/wsD X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: f8170843-4a04-4a9e-e31c-08db19238af3 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2023 00:34:26.6669 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR09MB3593 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256927 Archived-At: Dmitry Gutov writes: > On 27/02/2023 16:15, Arthur Miller wrote: > >>> We could change project-try-vc to follow the link to the parent repo, but how is >>> the rest of it going to work? >>> >>> If the project root is the parent repo, which set of files would (project-files >>> pr) return? And how could that be implemented? >> I don't know how it works now, so I can't really tell you, but you have called >> git root "actual git root", so perhaps something that differentiate between >> directory hierarchy root (worktree), and real git root (project). Perhaps >> project-vc-root, if you don't already use that name, or something similar? > > Do you mean you want a separate helper to get to the "worktree parent" > repository? I wouldn't call it "worktree parent", because it relatively git specific; if you prefer to be project neutral; but something like that yes. > repository? We could add something like that to VC, I guess. But your own code > seems to be working well too. I didn't meant to ask for someone to write it for me :), I can use my own code, but as said I had somewhat different expectation from project.el when I did this request. You can just close it, it is ok; I am sorry for the trouble. > I haven't had a use for "worktree parent" myself, though. And until we get a > good idea for how people will use a feature, it's a little difficult to choose a > place for it. If you have a branch "main", work in a branch X, and would like to test/fix something unrelated to X, wouldn't you create a new workree Y from clean "main"? It is a bit special case, which I personally use, so to automate this, "worktree" as root is not enough, I need the actual root. For other purposes I need the worktree. So as said, both are needed. Of course, worktree will be used more frequently for natural reasons. More general case is to create patch for some unrelated branch Z, in which case I am not sure, but I believe I need to exec git branch and/or git worktree list and parse the output to see where to jump, and from which branch and directory to create a new worktree. >>>> Yes that is what I wanted? :-). >>>> For automation purpose I need to find the project root, so I can pull sources >>>> to >>>> main, create a clean worktree from main, and switch Emacs to the new worktree >>>> interactively in one command, like M-x make-new-patch. Emacs asks me for a name >>>> and create a clean worktree from the main trunk for current project. Actually >>>> better variant is to ask which branch to patch, but the first one is slightly >>>> faster and works just fine in many cases. >>> >>> It sounds like your code is Git-specific, not project-neutral. >> Yepp. Question is what project.el then really is, if it can't handle vc >> specific >> "projects", if it is only synomim for operations on directory trees? Perhpas it >> should be called dirtree.el, because that is what it does: it works on >> directory trees and uses "project markers" to know where to start/stop? I am not >> trying to by sarcastic or negative. > > It uses VCS-specific information and converts it to a shape that should be > usable without the caller being aware of which underlying data that information > is determined by. > > In particular, it reads .gitmodules, .git and .gitignore. > > And, well, different backends can make different decisions on the backends's > behavior. But, ideally, it should be good for the majority of uses. Such as our > built-in commands, for example: project-vc-dir, project-eshell, etc. Yes, they are nice, and they illustrate that for some purpose, worktree is needed. >> I don't mean it is not useful, we need both, >> operations that work as projectile/project, on directory trees, but also those >> that actually understand a possible project structure. To me projectile and now >> project.el seems more like they are an extension to Dired, not in some negative >> connotation, but at least conceptually, then really project handling. I am not >> trying to be negative, I am a bit oversimplistic and exaggerating, becuase I am >> trying to illustrate the difference how I think about "projects". > > It a way -- yes, because we describe a project as a set of files. With a > well-defined root. But it doesn't absolutely have to be in the shape of a single > directory tree, though it usually is. > > Whenever one chooses a different shape, though, they should consider how that > will affect the common uses. It is not about the shape; you can put a worktree as a subdirectory in a main repository, it does not need to be out of source tree; project.el will still not find the real git root. You can test it yourself in Emacs source: In Emacs repo create new worktree: git worktree add new-test; change to newly created folder and test your tools, they will work only on new-test. >> Version control has become an integral part of all projects, at least in >> software industry, just as building projects, boilerplate generating projects >> etc. What I am saying is that project-neutral is OK, we don't want just a >> different name for Git commands, but any project library nowadays should be able >> to work with vc systems, build systems etc. At least for software management >> projects. > > You seem to be assigning a lot of meaning to the fact that the root doesn't > point to "worktree root", but to the current repository root (modulo the search > in the parent directory when the current repo is detemined to be a submodule). > > But would it be a better choice? I don't think it is either one; definitely not an exclusive choice. I tried to say that we need both. But the root :) of this discussion, is that I missunderstood project.el as an attempt to create a useful middleware for general working with projects, but I guess you and other authors are more seeing it as an end-user application. I appologize, I should have probably looked more into the code and asked. I just tried to use some functions :). > When I use worktrees, it's to carry on development in a certain branch. Meaning, > I need to be able to pull/push/commit in that branch, all within the same > worktree. Yes, in some cases that is a workflow. But there are cases when its prefered to checkout other branch, while work on something else; and as said above, in that case is prefered to make a new worktree from either "clean" main or some other branch. > To do a pull, or to run some commands in that worktree, I can call > project-eshell. To do a commit, I can call up project-vc-dir. In both cases, the > useful thing to do for 'project-root' is to return the current repository root, > not the worktree parent. Because you don't make new commits in the parent repo > when working on a worktree, you make them in the current one. In this cases yes; but in some other cases no. Uses you mention are definitely more frequent, then checking out unrelated branch, but I don't think it is so uncommon either. > I'm all for adding new Version Control related features, but they should be > based off realistic, specific user scenarios. Automation. I don't want to open terminal (or magit, does not matter), switch branches and do that stuff manually (if I don't have to). >>> But you still could find the worktree root using project.el, and then read the >>> contents of .git, follow the link and do your automation stuff. >> Yeah, but it what does it saves me? In Git case it is really synonym to: >> (git-dir (locate-dominating-file directory ".git")) >> I can just as well call built-in function instead of requiring project.el. > > Sure. locate-dominating-file is an underrated function. If you just want to find > the current repository root (no matter if it's a submodule or etc), the above > will easily work. project-try-vc adds some caching on top of that, but you might > not need it. I didn't know you have caching in project.el; that is a good feature to have. I personally don't need it, but definitely good to know it is there. >> As said I thought project.el was more general to work with projects on a deeper >> level, sort-of EDE replacement or complement, and I wanted to use it as library, >> but I understand now it is not. > > The idea was for a more simple/transparent and extensible EDE alternative. Or an > extension point to plug Projectile in. Ede is extensible; it is just a bit arcane and there is not too much documentation, unfortunately. I would prefer if Ede was re-used instead of the duplicated effort, but I do understand if you want to replace it. > It can still grow some additions (such as build tool support), but for now we > have what we have. In my opinion, Emacs lacks 1) a good and easy to use boiler-plate generator framework. Ede is meant for that, but it is arcane to use and is meant to be used with existing projects. Also, Emacs will automatically create a new folder if asked to find-file, when folder does not exists. But, if a foder exists, it creates new file in that folder, which is not preferred behavior. In the end, as an end-user I have to manually create folders or run scripts before I can ask Ede to fill-in with some code generator. There is no reason to not automate project generation. We do have all the tools in Emacs already but I haven't seen any good generator. Maybe there is some, but I am not aware of one. I am playing with a little framework based on org-capture; but it is nothing polished I wish to share with anyone. With boilerplate I mean init git, generate readme, lsp database, makefiles and that sort of stuff. I think a combo between Ede and project.el would be nice. 2) better integration with tools for common workflow(s). Adding features, fixes, tests etc, is mostly about creating a new patch, which with addition of worktrees in Git can be super nicely automated. For example: add new library, or add new executable, or add new fix, it all boiles down to add new branch which leads to add new worktree, add a possible target in Makefile, create possibly a test file, probably some other thing. It would be nice to be able to say: M-x add-new-shared-library or M-x add-new-executable, or M-x add-new-fix and Emacs will do at least initial boilerplate. If you plan to add build tool support to project.el, it would be welcome :).