From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Tue, 28 Feb 2023 00:39:48 +0200 Message-ID: <59fa389f-d954-8f5b-6378-fc28a60e98aa@yandex.ru> References: <5dea8e3b-4867-52f8-19fb-9bf5ab167f46@yandex.ru> <66ce5a8f-5321-47b2-b605-38a6aea19190@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22908"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Cc: 61817@debbugs.gnu.org To: Arthur Miller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 27 23:40: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 1pWmAR-0005ls-2X for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Feb 2023 23:40:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pWmA8-0000uj-VI; Mon, 27 Feb 2023 17:40:04 -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 1pWmA6-0000t5-In for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 17:40: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 1pWmA6-0003yd-9u for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 17:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pWmA6-0000B7-4d for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 17:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Feb 2023 22:40:02 +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.1677537600673 (code B ref 61817); Mon, 27 Feb 2023 22:40:02 +0000 Original-Received: (at 61817) by debbugs.gnu.org; 27 Feb 2023 22:40:00 +0000 Original-Received: from localhost ([127.0.0.1]:49114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWmA3-0000An-Ci for submit@debbugs.gnu.org; Mon, 27 Feb 2023 17:39:59 -0500 Original-Received: from mail-wm1-f49.google.com ([209.85.128.49]:40591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWmA1-0000AQ-6d for 61817@debbugs.gnu.org; Mon, 27 Feb 2023 17:39:57 -0500 Original-Received: by mail-wm1-f49.google.com with SMTP id fm20-20020a05600c0c1400b003ead37e6588so8264509wmb.5 for <61817@debbugs.gnu.org>; Mon, 27 Feb 2023 14:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=gbGiO6yBvrFbcqeBoVUz+pE9lvCiWmDchPGxDtdwprc=; b=FxTQG/ZhobqYBwSNYbJho1To5Z5f22hzwySYvm/GNxzTnLth35kC+JV+T7IV8TsK4Y 5DhlNK691s4xI9LtpXV8nA52kySseDly7RsXE6Y2VDFVLTZ43RR4Ie3zDQ3OPFD43PJP IvqHudGBSLBrnvs8lsefff8l5L7QuogDpFvS/nUjCSPoED5c6Oy57y+AMdetgB0HDvng +4Koe2giaO8WU4X0aQCyvG8cJz0uqa9EedmLo0NUmE8XdK+hqzg6D5kW5xhtzD2vcGUT 7BNUMvpQGSzRD8IQty4z7d2+mPY7IX+aVWpKs9WANpZmc0A2XXjmM4Ad/BxWmnmC7WjM EXKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gbGiO6yBvrFbcqeBoVUz+pE9lvCiWmDchPGxDtdwprc=; b=nrvwJVAwi6xWa5GZlN5SuXSMB88l86nXWMMS9sKdmzKeqx7MT5QjsRxFOve9iaXnND ow9DhZuEKu1ODRp3ibdV+lecNhyqpX+52rbvVRMUUi9DBcvGDE0HN+/hXev9t5DkeS+a 2cS3Bs5Q+B12W7ZKqS/cbLZDgThQJYkTwav9YkYAGMlOM5Vgs1bnIjrU/Ln8IEsqqM8X Vnt2rR0m9BEP4Ttc+tB7+3RJqN6Oc1x+PD+lMazpwO0sA41y2i+3hahv5BgKPkSNUz3U UHQ9tY5qaJjW4aDK0v6AO3yt6/Qe0+rl6YHcAHMdAAuvHqR0GfttGIVywZGV0iBL8L/j z8Vw== X-Gm-Message-State: AO0yUKU8Dw0rlaVQmbTuLonfQYo0P5oQ27b77gOLXMAiAzxX0h0NN/Rf lDWxYAVj9Ei4LeoqmlhwGGI= X-Google-Smtp-Source: AK7set/j8bx8AB6SB8x4fI9PBNQe9epA3yQ1rLjnF0xkdcOYOxbrfPWK1QbgkZBMP2g17e0LPSszKw== X-Received: by 2002:a05:600c:1616:b0:3eb:86a:6bb0 with SMTP id m22-20020a05600c161600b003eb086a6bb0mr488141wmn.35.1677537591083; Mon, 27 Feb 2023 14:39:51 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s14-20020a05600c45ce00b003daf6e3bc2fsm315454wmo.1.2023.02.27.14.39.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Feb 2023 14:39:50 -0800 (PST) Content-Language: en-US In-Reply-To: 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:256919 Archived-At: 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? We could add something like that to VC, I guess. But your own code seems to be working well too. 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. >>> 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. > 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. > 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? 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. 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. I'm all for adding new Version Control related features, but they should be based off realistic, specific user scenarios. >> 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. > 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. It can still grow some additions (such as build tool support), but for now we have what we have.