bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 27/02/2023 09:32, Arthur Miller wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> On 26/02/2023 18:23, Arthur Miller wrote:
>>>> What actions trigger the bug:
>>>> Two different, unrelated repositories with emacs source code tree. My 
>>>> tree(s)
>>>> looks like this:
>>>> ~/repos/emsrc/emacs/
>>>> ~/repos/enacs-tests/emacs/
>>>> Where in both the last "emacs/" is the Emacs source tree from main git
>>>> repository.
>>>> ~/repos/emsrc/emacs/  is the one I use for my "everyday" Emacs. I build 
>>>> Emacs
>>>> now
>>>> and then once in a week or few weeks with a script, and I make each build 
>>>> in its
>>>> own our-of-source worktree. The other one is one where I used to do some 
>>>> tests.
>>>> It shouldn't matter since all worktrees are contained withing parent 
>>>> directory,
>>>> which in one case is "emsrc" and in the other case "emacs-tests", but for 
>>>> some
>>>> reason project.el sees the wrong one.
>>>> 1. create two parent folders each one containing a copy of emacs sources
>>>> 1. create out of source worktree for Emacs source under one of those
>>>> 2. navigate to the worktree/lisp/progmodes
>>>> 3. run M-: (project-known-project-roots)
>>>> In my Emacs, I am in my currently installed emacs worktree, where git root 
>>>> is
>>>> ~/repos/emsrc/emacs but project.el returns ("~/repos/emacs-tests/emacs/") 
>>>> as a
>>>> result
>>>
>>> What does (project-root (project-current)) return? And which dirs you are
>>> testing it in?
>> It returns the current worktree folder:
>> "/home/arthur/repos/emsrc/no-gtk-with-cairo-and-native-230226-061643/"
>> which I guess is what project.el finds as root since it only uses .git as a
>> marker, if I understand correctly what you write little further.
>> 
>>>> I am not chasing the bug, but I don't see much code in project.el related
>>>> to worktrees.
>>>
>>> Normally, there shouldn't be any need to handle worktree specially: it 
>>> contains
>>> a file called .git at the top which can serve as a marker just fine.
>> Well define "normally" and "just fine" :). Anyway, when I read your reply it
>> seems
>> like I have wrong expectation from project.el, so the fault is on my side. I
>> thought it can deal with git projects in general, but as I understand it 
>> then,
>> it only works with files in current directory.
>
> 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?

>>>> The only place I see them mentioned is about submodules.I
>>>> personally have used this one for quite some time, and it seems to 
>>>> correctly
>>>> handle worktrees for me:
>>>
>>> You code looks like it can return the "actual git root" that can be a 
>>> directory
>>> residing somewhere else than the current directory tree.
>> Git worktrees can be placed outside the main repository tree:
>>      git worktree add ../my-new-shiny-emacs-patch
>> as an example. The code will find correct git root both outside, or within 
>> the
>> repo.
>
> Exactly.
>
>> But I think it should be done by actually asking git to list worktrees
>> instead.
>> 
>>>                                                           Is that what you
>>> wanted?
>> 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. 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".

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. 

> 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.

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.