* Getting path to a file from arbitrary project directory
@ 2023-06-23 8:52 Konstantin Kharlamov
2023-06-23 9:45 ` SZEDER Gábor
2023-06-23 9:52 ` Junio C Hamano
0 siblings, 2 replies; 5+ messages in thread
From: Konstantin Kharlamov @ 2023-06-23 8:52 UTC (permalink / raw)
To: git
(please keep me CC'ed, I'm not subscribed)
Hello! I'm trying to solve a simple problem: while I am inside an arbitrary project directory, I want to get a path to a file `filename.c` located elsewhere in the same project.¹
One way to implement that is with a command chain:
cd $(git rev-parse --show-toplevel) && git ls-files --full-name -- "*filename.c"
But it is pretty clunky, because that requires you to modify state (changing current directory). It may not matter though, but I'm just wondering if there's a better way to do that, something like `git ls-files --top -- …`, or anything like that? Haven't found nothing similar in `man git-ls-files`.
As a separate note, this doesn't work:
ls-files --full-name -- $(git rev-parse --show-toplevel)"*filename.c"
1: the usecase is I have a Emacs helper function to pick up a an aribtrarily mangled path to a file in the project from the primary clipboard and open that file. It's often "mangled", because gdb prints it with `../`, then logs print no path whatsoever, just a filename… So it's generally useful to have.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting path to a file from arbitrary project directory
2023-06-23 8:52 Getting path to a file from arbitrary project directory Konstantin Kharlamov
@ 2023-06-23 9:45 ` SZEDER Gábor
2023-06-23 10:02 ` Konstantin Kharlamov
2023-06-23 9:52 ` Junio C Hamano
1 sibling, 1 reply; 5+ messages in thread
From: SZEDER Gábor @ 2023-06-23 9:45 UTC (permalink / raw)
To: Konstantin Kharlamov; +Cc: git
On Fri, Jun 23, 2023 at 11:52:58AM +0300, Konstantin Kharlamov wrote:
> (please keep me CC'ed, I'm not subscribed)
>
> Hello! I'm trying to solve a simple problem: while I am inside an arbitrary project directory, I want to get a path to a file `filename.c` located elsewhere in the same project.¹
>
> One way to implement that is with a command chain:
>
> cd $(git rev-parse --show-toplevel) && git ls-files --full-name -- "*filename.c"
>
> But it is pretty clunky, because that requires you to modify state (changing current directory). It may not matter though, but I'm just wondering if there's a better way to do that, something like `git ls-files --top -- …`, or anything like that? Haven't found nothing similar in `man git-ls-files`.
When a command expects pathspecs as arguments, then in general the
leading ':/' magic means the root of the working tree (not sure where
it is documented, though), i.e. you could try this:
git ls-files --full-name ':/*filename.c'
> As a separate note, this doesn't work:
>
> ls-files --full-name -- $(git rev-parse --show-toplevel)"*filename.c"
>
> 1: the usecase is I have a Emacs helper function to pick up a an aribtrarily mangled path to a file in the project from the primary clipboard and open that file. It's often "mangled", because gdb prints it with `../`, then logs print no path whatsoever, just a filename… So it's generally useful to have.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting path to a file from arbitrary project directory
2023-06-23 8:52 Getting path to a file from arbitrary project directory Konstantin Kharlamov
2023-06-23 9:45 ` SZEDER Gábor
@ 2023-06-23 9:52 ` Junio C Hamano
2023-06-23 10:02 ` Konstantin Kharlamov
1 sibling, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2023-06-23 9:52 UTC (permalink / raw)
To: Konstantin Kharlamov; +Cc: git
Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 1: the usecase is I have a Emacs helper function to pick up a an
> aribtrarily mangled path to a file in the project from the primary
> clipboard and open that file. It's often "mangled", because gdb
> prints it with `../`, then logs print no path whatsoever, just a
> filename… So it's generally useful to have.
Sounds like you are looking for the top (and possibly glob) magic
pathspec, e.g. in the source tree of Git itself, I can go a few
levels down into a random directory and get exactly the same listing
of two files whose name is "rerere.c" located in two directories:
$ cd t/helper
$ git ls-files --full-name ':(top,glob)**/rerere.c'
builtin/rerere.c
rerere.c
Look for magic pathspec in "git help glossary" to learn more.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting path to a file from arbitrary project directory
2023-06-23 9:45 ` SZEDER Gábor
@ 2023-06-23 10:02 ` Konstantin Kharlamov
0 siblings, 0 replies; 5+ messages in thread
From: Konstantin Kharlamov @ 2023-06-23 10:02 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
Thank you very much, works for me!
On Fri, 2023-06-23 at 11:45 +0200, SZEDER Gábor wrote:
> On Fri, Jun 23, 2023 at 11:52:58AM +0300, Konstantin Kharlamov wrote:
> > (please keep me CC'ed, I'm not subscribed)
> >
> > Hello! I'm trying to solve a simple problem: while I am inside an arbitrary
> > project directory, I want to get a path to a file `filename.c` located
> > elsewhere in the same project.¹
> >
> > One way to implement that is with a command chain:
> >
> > cd $(git rev-parse --show-toplevel) && git ls-files --full-name --
> > "*filename.c"
> >
> > But it is pretty clunky, because that requires you to modify state (changing
> > current directory). It may not matter though, but I'm just wondering if
> > there's a better way to do that, something like `git ls-files --top -- …`,
> > or anything like that? Haven't found nothing similar in `man git-ls-files`.
>
> When a command expects pathspecs as arguments, then in general the
> leading ':/' magic means the root of the working tree (not sure where
> it is documented, though), i.e. you could try this:
>
> git ls-files --full-name ':/*filename.c'
>
>
> > As a separate note, this doesn't work:
> >
> > ls-files --full-name -- $(git rev-parse --show-
> > toplevel)"*filename.c"
> >
> > 1: the usecase is I have a Emacs helper function to pick up a an aribtrarily
> > mangled path to a file in the project from the primary clipboard and open
> > that file. It's often "mangled", because gdb prints it with `../`, then logs
> > print no path whatsoever, just a filename… So it's generally useful to have.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Getting path to a file from arbitrary project directory
2023-06-23 9:52 ` Junio C Hamano
@ 2023-06-23 10:02 ` Konstantin Kharlamov
0 siblings, 0 replies; 5+ messages in thread
From: Konstantin Kharlamov @ 2023-06-23 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Thank you, it works!
On Fri, 2023-06-23 at 02:52 -0700, Junio C Hamano wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>
> > 1: the usecase is I have a Emacs helper function to pick up a an
> > aribtrarily mangled path to a file in the project from the primary
> > clipboard and open that file. It's often "mangled", because gdb
> > prints it with `../`, then logs print no path whatsoever, just a
> > filename… So it's generally useful to have.
>
> Sounds like you are looking for the top (and possibly glob) magic
> pathspec, e.g. in the source tree of Git itself, I can go a few
> levels down into a random directory and get exactly the same listing
> of two files whose name is "rerere.c" located in two directories:
>
> $ cd t/helper
> $ git ls-files --full-name ':(top,glob)**/rerere.c'
> builtin/rerere.c
> rerere.c
>
> Look for magic pathspec in "git help glossary" to learn more.
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-23 10:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-23 8:52 Getting path to a file from arbitrary project directory Konstantin Kharlamov
2023-06-23 9:45 ` SZEDER Gábor
2023-06-23 10:02 ` Konstantin Kharlamov
2023-06-23 9:52 ` Junio C Hamano
2023-06-23 10:02 ` Konstantin Kharlamov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.