Tôi có thể sử dụng Git để tìm kiếm các tên tệp phù hợp trong kho lưu trữ không?

Chỉ cần nói rằng tôi có một tệp: "HelloWorld.pm" trong nhiều thư mục con trong kho lưu trữ Git.

Tôi muốn phát hành một lệnh để tìm đường dẫn đầy đủ của tất cả các tệp khớp với "HelloWorld.pm":

Ví dụ:

/path/to/repository/HelloWorld.pm
/path/to/repository/but/much/deeper/down/HelloWorld.pm
/path/to/repository/please/dont/make/me/search/through/the/lot/HelloWorld.pm

Làm cách nào tôi có thể sử dụng Git để tìm một cách hiệu quả tất cả các đường dẫn đầy đủ phù hợp với một tên tệp nhất định?

Tôi nhận ra mình có thể thực hiện việc này bằng lệnh tìm Linux / Unix nhưng tôi đã hy vọng tránh quét tất cả các thư mục con để tìm kiếm các bản sao của tên tệp.

git ls-filessẽ cung cấp cho bạn danh sách tất cả các tệp ở trạng thái hiện tại của kho lưu trữ (bộ nhớ cache hoặc chỉ mục). Bạn có thể chuyển một mẫu vào để nhận các tệp phù hợp với mẫu đó.

git ls-files HelloWorld.pm '**/HelloWorld.pm'

Nếu bạn muốn tìm một tập hợp các tệp và tra cứu nội dung của chúng, bạn có thể làm điều đó với git grep:

git grep some-string -- HelloWorld.pm '**/HelloWorld.pm'

Hmm, câu hỏi ban đầu là về kho lưu trữ. Một kho lưu trữ chứa nhiều hơn 1 cam kết (trong trường hợp chung là ít nhất), nhưng các câu trả lời được đưa ra trước khi tìm kiếm chỉ thông qua một cam kết.

Bởi vì tôi không thể tìm thấy câu trả lời thực sự tìm kiếm toàn bộ lịch sử cam kết, tôi đã viết một tập lệnh nhanh brute force git-find-by-name mà (gần như) xem xét tất cả các cam kết.

#! /bin/sh
tmpdir=$(mktemp -td git-find.XXXX)
trap "rm -r $tmpdir" EXIT INT TERM

allrevs=$(git rev-list --all)
# well, nearly all revs, we could still check the log if we have
# dangling commits and we could include the index to be perfect...

for rev in $allrevs
do
  git ls-tree --full-tree -r $rev >$tmpdir/$rev 
done

cd $tmpdir
grep $1 * 

Có lẽ có một cách thanh lịch hơn.

Xin lưu ý rằng cách thông số được truyền vào grep, vì vậy nó sẽ khớp với các phần của tên tệp. Nếu điều đó không được mong muốn, hãy neo biểu thức tìm kiếm của bạn và / hoặc thêm các tùy chọn grep phù hợp.

Đối với lịch sử sâu, đầu ra có thể quá ồn ào, tôi đã nghĩ về một tập lệnh chuyển đổi danh sách các bản sửa đổi thành một phạm vi, giống như điều ngược lại với những gì git rev-list có thể làm. Nhưng cho đến nay nó vẫn chỉ là một suy nghĩ.

Thử:

git ls-tree -r HEAD | grep HelloWorld.pm

git ls-files | grep -i HelloWorld.pm

Grep -i làm cho grep không phân biệt chữ hoa và chữ thường.

[Tôi thừa nhận đó là một chút lạm dụng bình luận, nhưng tôi chưa thể bình luận và nghĩ rằng tôi sẽ cải thiện câu trả lời của @ uwe-geuder.]

#!/bin/bash
#
#

# I'm using a fixed string here, not a regular expression, but you can easily
# use a regular expression by altering the call to grep below.
name="$1"

# Verify usage.
if [[ -z "$name" ]]
then
    echo "Usage: $(basename "$0") <file name>" 1>&2
    exit 100
fi  

# Search all revisions; get unique results.
while IFS= read rev
do
    # Find $name in $rev's tree and only use its path.
    grep -F -- "$name" \
        <(git ls-tree --full-tree -r "$rev" | awk '{ print $4 }')
done < \
    <(git rev-list --all) \
    | sort -u

Một lần nữa, hãy +1 đến @ uwe-geuder để có câu trả lời tuyệt vời.

Nếu bạn quan tâm đến BASH:

Trừ khi bạn được đảm bảo về khả năng tách từ trong vòng lặp for (như khi sử dụng một mảng như thế này for item in "${array[@]}":), tôi thực sự khuyên bạn nên sử dụng while IFS= read var ; do ... ; done < <(command)khi đầu ra lệnh mà bạn đang lặp lại được phân tách bằng các dòng mới (hoặc read -d''khi đầu ra được phân tách bằng chuỗi null $'\0'). Mặc dù git rev-list --allđược đảm bảo sử dụng chuỗi thập lục phân 40 byte (không có dấu cách), tôi không bao giờ muốn chấp nhận. Bây giờ tôi có thể dễ dàng thay đổi lệnh từ git rev-list --allbất kỳ lệnh nào tạo ra các dòng

Tôi cũng khuyên bạn nên sử dụng cơ chế BASH tích hợp để đưa đầu vào và lọc đầu ra thay vì các tệp tạm thời.

Tập lệnh của Uwe Geuder (@ uwe-geuder) rất tuyệt nhưng thực sự không cần phải đổ từng đầu ra ls-tree vào thư mục riêng, chưa được lọc.

Nhanh hơn nhiều và sử dụng ít dung lượng hơn: Chạy grep trên đầu ra và sau đó lưu trữ nó, như được hiển thị trong ý chính này