Git development
 help / color / mirror / Atom feed
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox