ข้อตกลงใดมีหยดนี้?


149

เมื่อแฮชของหยดมีวิธีรับรายการการกระทำที่มีหยดนี้อยู่ในต้นไม้หรือไม่?


2
"Hash of a blob" คือการส่งคืนโดยgit hash-objectหรือsha1("blob " + filesize + "\0" + data)ไม่ใช่แค่ sha1sum ของเนื้อหาหยด
Ivan Hamilton

1
ตอนแรกฉันคิดว่าคำถามนี้ตรงกับคำถามของฉัน แต่ดูเหมือนว่าจะไม่ ฉันต้องการที่จะรู้ว่าคนที่กระทำซึ่งเป็นครั้งแรกที่นำเสนอหยดนี้ไปยังพื้นที่เก็บข้อมูล
Jesse Glick

หากคุณรู้จัก filepath คุณสามารถใช้git log --follow filepath(และใช้สิ่งนี้เพื่อเร่งความเร็วโซลูชันของ Aristotle หากคุณต้องการ)
Zaz

protip ™: หนึ่งใส่ของสคริปต์รล์ในและชื่อ~/.bin จากนั้นคุณสามารถใช้กับgit-find-object git find-object
Zaz

1
หมายเหตุ: ด้วย Git 2.16 (ไตรมาสที่ 1 ปี 2018), คุณอาจจะพิจารณาเพียงgit describe <hash>: ดูคำตอบของฉันด้านล่าง
VonC

คำตอบ:


107

สคริปต์ต่อไปนี้ทั้งคู่ใช้ SHA1 ของ blob เป็นอาร์กิวเมนต์แรกและหลังจากนั้นอาร์กิวเมนต์ที่git logอาจเข้าใจได้ เช่น--allค้นหาในทุกสาขาแทนที่จะเป็นสาขาปัจจุบันหรือ-gค้นหาใน reflog หรืออะไรก็ตามที่คุณชอบ

ที่นี่มันเป็นเชลล์สคริปต์ - สั้นและหวาน แต่ช้า:

#!/bin/sh
obj_name="$1"
shift
git log "$@" --pretty=format:'%T %h %s' \
| while read tree commit subject ; do
    if git ls-tree -r $tree | grep -q "$obj_name" ; then
        echo $commit "$subject"
    fi
done

และรุ่นที่ได้รับการปรับปรุงใน Perl ยังค่อนข้างสั้น แต่เร็วกว่ามาก:

#!/usr/bin/perl
use 5.008;
use strict;
use Memoize;

my $obj_name;

sub check_tree {
    my ( $tree ) = @_;
    my @subtree;

    {
        open my $ls_tree, '-|', git => 'ls-tree' => $tree
            or die "Couldn't open pipe to git-ls-tree: $!\n";

        while ( <$ls_tree> ) {
            /\A[0-7]{6} (\S+) (\S+)/
                or die "unexpected git-ls-tree output";
            return 1 if $2 eq $obj_name;
            push @subtree, $2 if $1 eq 'tree';
        }
    }

    check_tree( $_ ) && return 1 for @subtree;

    return;
}

memoize 'check_tree';

die "usage: git-find-blob <blob> [<git-log arguments ...>]\n"
    if not @ARGV;

my $obj_short = shift @ARGV;
$obj_name = do {
    local $ENV{'OBJ_NAME'} = $obj_short;
     `git rev-parse --verify \$OBJ_NAME`;
} or die "Couldn't parse $obj_short: $!\n";
chomp $obj_name;

open my $log, '-|', git => log => @ARGV, '--pretty=format:%T %h %s'
    or die "Couldn't open pipe to git-log: $!\n";

while ( <$log> ) {
    chomp;
    my ( $tree, $commit, $subject ) = split " ", $_, 3;
    print "$commit $subject\n" if check_tree( $tree );
}

8
FYI คุณต้องใช้ SHA แบบเต็มของ Blob คำนำหน้าแม้ว่าจะไม่ซ้ำกันจะไม่ทำงาน ในการรับ SHA แบบเต็มรูปแบบจากคำนำหน้าคุณสามารถใช้git rev-parse --verify $theprefix
John Douthat

1
ขอบคุณ @JohnDouthat สำหรับความคิดเห็นนี้ ต่อไปนี้เป็นวิธีการรวมเข้าไว้ในสคริปต์ด้านบน (ขออภัยในความคิดเห็นแบบอินไลน์): my $blob_arg = shift; open my $rev_parse, '-|', git => 'rev-parse' => '--verify', $blob_arg or die "Couldn't open pipe to git-rev-parse: $!\n"; my $obj_name = <$rev_parse>; chomp $obj_name; close $rev_parse or die "Couldn't expand passed blob.\n"; $obj_name eq $blob_arg or print "(full blob is $obj_name)\n";
Ingo Karkat

อาจมีข้อผิดพลาดในสคริปต์เชลล์บน ห่วงในขณะที่ดำเนินการเฉพาะในกรณีที่มีสายการอ่านมากขึ้นและด้วยเหตุผลใดก็ตามบันทึก git ไม่ได้วาง crlf สุดท้ายในตอนท้าย ฉันต้องเพิ่มตัวดึงข้อมูลบรรทัดและละเว้นบรรทัดว่างเปล่า obj_name="$1" shift git log --all --pretty=format:'%T %h %s %n' -- "$@" | while read tree commit cdate subject ; do if [ -z $tree ] ; then continue fi if git ls-tree -r $tree | grep -q "$obj_name" ; then echo "$cdate $commit $@ $subject" fi done
Mixologic

7
สิ่งนี้จะค้นหากระทำได้เฉพาะที่สาขาปัจจุบันเว้นแต่คุณจะผ่าน--allการโต้แย้งเพิ่มเติม (การค้นหาการทำธุรกรรมซื้อคืนทั้งหมดนั้นมีความสำคัญในบางกรณีเช่นการลบไฟล์ขนาดใหญ่ออกจากประวัติการซื้อคืน )
peterflynn

1
คำแนะนำ: ส่งผ่านแฟล็ก -g ไปยังเชลล์สคริปต์ (หลัง ID อ็อบเจ็กต์) เพื่อตรวจสอบ reflog
Bram Schoenmakers

24

น่าเสียดายที่สคริปต์ช้าไปหน่อยสำหรับฉันดังนั้นฉันจึงต้องปรับให้เหมาะสมเล็กน้อย โชคดีที่ฉันไม่เพียง แต่มีแฮช แต่ยังเป็นเส้นทางของไฟล์

git log --all --pretty=format:%H -- <path> | xargs -n1 -I% sh -c "git ls-tree % -- <path> | grep -q <hash> && echo %"

1
คำตอบที่ยอดเยี่ยมเพราะมันง่ายมาก เพียงแค่ตั้งสมมติฐานอย่างสมเหตุสมผลว่าเส้นทางนั้นเป็นที่รู้จัก อย่างไรก็ตามหนึ่งควรทราบว่ามันส่งกลับกระทำที่เส้นทางถูกเปลี่ยนเป็นแฮชที่กำหนด
Unapiedra

1
หากใครต้องการคอมมิทล่าสุดที่มี<hash>at ที่ให้ไว้<path>เอา<path>อาร์กิวเมนต์ออกจากgit logพินัยกรรมจะใช้งานได้ ผลลัพธ์ที่ส่งกลับครั้งแรกคือความมุ่งมั่นที่ต้องการ
Unapiedra

10

เมื่อแฮชของหยดมีวิธีรับรายการการกระทำที่มีหยดนี้อยู่ในต้นไม้หรือไม่?

ด้วย Git 2.16 (ไตรมาสที่ 1 ปี 2561) git describeจะเป็นทางออกที่ดีเนื่องจากได้รับการสอนให้ขุดต้นไม้ให้ลึกเพื่อค้นหาสิ่ง<commit-ish>:<path>ที่หมายถึงวัตถุหยดที่กำหนด

ดูกระทำ 644eb60 , กระทำ 4dbc59a , กระทำ cdaed0c , กระทำ c87b653 , กระทำ ce5b6f9 (16 พฤศจิกายน 2017) และกระทำ 91904f5 , กระทำ 2deda00 (2 พฤศจิกายน 2017) โดยสเตฟานสนั่น (stefanbeller )
(รวมโดยJunio C Hamano - gitster-ในการกระทำ 556de1a , 28 ธันวาคม 2017)

builtin/describe.c: อธิบายหยด

บางครั้งผู้ใช้จะได้รับการแฮชของวัตถุและพวกเขาต้องการระบุเพิ่มเติม (เช่น: ใช้verify-packเพื่อค้นหา blobs ที่ใหญ่ที่สุด แต่สิ่งเหล่านี้คืออะไรหรือคำถามนี้ " ซึ่งกระทำมีหยดนี้? ")

เมื่ออธิบายการคอมมิทเราพยายามยึดให้แท็กหรือการอ้างอิงเนื่องจากสิ่งเหล่านี้เป็นแนวคิดในระดับที่สูงกว่าการคอมมิท และถ้าไม่มีการอ้างอิงหรือแท็กที่ตรงกันเราก็ไม่มีโชค
ดังนั้นเราจึงใช้ฮิวริสติกเพื่อสร้างชื่อให้กับคำมั่นสัญญา ชื่อเหล่านี้คลุมเครืออาจมีแท็กหรือการอ้างอิงที่แตกต่างกันและอาจมีเส้นทางที่แตกต่างกันใน DAG ที่จะเดินทางไปถึงการส่งมอบอย่างแม่นยำ

เมื่ออธิบาย blob เราต้องการอธิบาย blob จากเลเยอร์ที่สูงขึ้นเช่นกันซึ่งเป็นสิ่งอันดับ(commit, deep/path)ที่วัตถุต้นไม้ที่เกี่ยวข้องนั้นค่อนข้างไม่น่าสนใจ
หยดเดียวกันนี้สามารถอ้างอิงได้จากหลายคอมมิตดังนั้นเราจะตัดสินใจได้อย่างไรว่าจะใช้คอมมิทใด?

แพทช์นี้ใช้วิธีการที่ค่อนข้างไร้เดียงสา: เนื่องจากไม่มีพอยน์เตอร์กลับจากบล๊อกไปจนถึงคอมมิชชันที่เกิดขึ้นหยดเราจะเริ่มเดินจากเคล็ดลับที่มีอยู่แสดงรายการบล๊อคตามคำสั่งของคอมมิชชัน หยดเราจะพาคนแรกที่กระทำที่ระบุไว้หยด

ตัวอย่างเช่น:

git describe --tags v0.99:Makefile
conversion-901-g7672db20c2:Makefile

บอกเราMakefileที่มันเป็นในv0.99เป็นที่รู้จักในการกระทำ 7672db2

การเดินจะดำเนินการในลำดับย้อนกลับเพื่อแสดงการแนะนำของหยดแทนที่จะเกิดขึ้นล่าสุด

นั่นหมายถึงgit describeman pageเพิ่มไปยังวัตถุประสงค์ของคำสั่งนี้:

แทนที่จะอธิบายกระทำโดยใช้สามารถเข้าถึงแท็กล่าสุดจากมันจริงจะทำให้วัตถุชื่ออ่านของมนุษย์ขึ้นอยู่กับโทษใช้ได้เมื่อใช้เป็นgit describegit describe <blob>

หากวัตถุที่ให้หมายถึงหยดมันจะถูกอธิบายว่าเป็น<commit-ish>:<path>เช่นนั้นหยดสามารถพบได้<path>ในที่<commit-ish>ซึ่งตัวเองอธิบายการกระทำครั้งแรกที่หยดนี้เกิดขึ้นในการเดินกลับแก้ไขจากหัว

แต่:

ข้อบกพร่อง

วัตถุต้นไม้เช่นเดียวกับแท็กวัตถุไม่ได้ชี้ไปที่กระทำไม่สามารถอธิบาย
เมื่ออธิบายถึง blobs แท็กที่มีน้ำหนักเบาซึ่งชี้ไปที่ blobs จะถูกละเว้น แต่ Blob นั้นยังคงอธิบายว่า<committ-ish>:<path>แม้จะมีแท็กที่มีน้ำหนักเบาก็ดี


1
เหมาะสำหรับใช้ร่วมกับgit rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print substr($0,6)}' | sort --numeric-sort --key=2 -r | head -n 20ซึ่งจะส่งคืน blobs ที่ใหญ่ที่สุด 20 อันดับแรกให้กับคุณ จากนั้นคุณสามารถส่งผ่าน ID git describeหยดจากการส่งออกดังกล่าวข้างต้นไป ทำงานเป็นเสน่ห์! ขอบคุณ!
Alexander Pogrebnyak

7

ฉันคิดว่านี่จะเป็นสิ่งที่มีประโยชน์โดยทั่วไปดังนั้นฉันจึงเขียนสคริปต์ Perl ขึ้นมาเพื่อทำ:

#!/usr/bin/perl -w

use strict;

my @commits;
my %trees;
my $blob;

sub blob_in_tree {
    my $tree = $_[0];
    if (defined $trees{$tree}) {
        return $trees{$tree};
    }
    my $r = 0;
    open(my $f, "git cat-file -p $tree|") or die $!;
    while (<$f>) {
        if (/^\d+ blob (\w+)/ && $1 eq $blob) {
            $r = 1;
        } elsif (/^\d+ tree (\w+)/) {
            $r = blob_in_tree($1);
        }
        last if $r;
    }
    close($f);
    $trees{$tree} = $r;
    return $r;
}

sub handle_commit {
    my $commit = $_[0];
    open(my $f, "git cat-file commit $commit|") or die $!;
    my $tree = <$f>;
    die unless $tree =~ /^tree (\w+)$/;
    if (blob_in_tree($1)) {
        print "$commit\n";
    }
    while (1) {
        my $parent = <$f>;
        last unless $parent =~ /^parent (\w+)$/;
        push @commits, $1;
    }
    close($f);
}

if (!@ARGV) {
    print STDERR "Usage: git-find-blob blob [head ...]\n";
    exit 1;
}

$blob = $ARGV[0];
if (@ARGV > 1) {
    foreach (@ARGV) {
        handle_commit($_);
    }
} else {
    handle_commit("HEAD");
}
while (@commits) {
    handle_commit(pop @commits);
}

ฉันจะใส่ gitub นี้เมื่อฉันกลับถึงบ้านเย็นนี้

อัปเดต: ดูเหมือนว่ามีคนทำสิ่งนี้แล้ว ที่หนึ่งใช้ความคิดทั่วไปเหมือนกัน แต่มีรายละเอียดที่แตกต่างกันและการดำเนินการเป็นมากสั้น ฉันไม่รู้ว่าจะเร็วกว่านี้ แต่ประสิทธิภาพอาจไม่ได้เป็นปัญหาที่นี่!

อัปเดต 2: สำหรับสิ่งที่คุ้มค่าการใช้งานของฉันคือลำดับความสำคัญเร็วขึ้นโดยเฉพาะอย่างยิ่งสำหรับพื้นที่เก็บข้อมูลขนาดใหญ่ มันgit ls-tree -rเจ็บจริงๆ

อัปเดต 3: ฉันควรทราบว่าความคิดเห็นเกี่ยวกับประสิทธิภาพของฉันด้านบนนำไปใช้กับการใช้งานที่ฉันเชื่อมโยงด้านบนในการอัปเดตครั้งแรก การปฏิบัติของอริสโตเติลเทียบได้กับฉัน รายละเอียดเพิ่มเติมในความคิดเห็นสำหรับผู้ที่อยากรู้อยากเห็น


อืมมันจะเร็วขนาดนั้นได้อย่างไร? คุณกำลังเดินต้นไม้อยู่ใช่ไหม? git-ls-tree คุณหลีกเลี่ยงงานอะไร (หมายเหตุ: grep จะประกันตัวในนัดแรก SIGPIPE กำลัง git-ls-tree) เมื่อฉันลองมันฉันต้อง Ctrl-C สคริปต์ของคุณหลังจาก 30 วินาที; ของฉันทำใน 4
อริสโตเติล Pagaltzis

1
สคริปต์ของฉันแคชผลลัพธ์ของ subtrees ในแฮชต้นไม้%% ดังนั้นจึงไม่จำเป็นต้องค้นหาทรีย่อยที่ยังไม่ได้เปลี่ยน
Greg Hewgill

ที่จริงแล้วฉันกำลังลองใช้งานที่ฉันพบใน GitHub ที่ฉันเชื่อมโยง ของคุณเร็วขึ้นในบางกรณี แต่ขึ้นอยู่กับว่าไฟล์ที่คุณกำลังค้นหานั้นอยู่ที่จุดเริ่มต้นหรือจุดสิ้นสุดของรายการ ls-tree ที่เก็บของฉันมี 9574 ไฟล์อยู่ในนั้นตอนนี้
Greg Hewgill

นอกจากนี้ยังเกิดขึ้นกับฉันว่าประวัติโครงการที่ไม่เป็นเชิงเส้นบางอย่างอาจทำให้สคริปต์ของฉันทำงานมากกว่าที่จำเป็น (ต้องแก้ไข) นี่อาจเป็นสาเหตุที่ใช้เวลานานสำหรับคุณ ที่เก็บข้อมูลของฉันเป็นกระจก git-svn ของคลังเก็บโค่นล้มดังนั้นมันจึงเป็นเส้นตรง
Greg Hewgill

แทนที่จะแยกไฟล์ cat เพื่อให้ต้นไม้ทำgit rev-parse $commit^{}
jthill

6

ในขณะที่คำถามดั้งเดิมไม่ได้ขอให้ฉันคิดว่ามันเป็นประโยชน์ที่จะตรวจสอบพื้นที่การแสดงละครเพื่อดูว่ามีการอ้างอิงหยด ฉันปรับเปลี่ยนสคริปต์ทุบตีดั้งเดิมเพื่อทำสิ่งนี้และพบสิ่งที่อ้างอิงถึงบล็อกเสียหายในที่เก็บของฉัน:

#!/bin/sh
obj_name="$1"
shift
git ls-files --stage \
| if grep -q "$obj_name"; then
    echo Found in staging area. Run git ls-files --stage to see.
fi

git log "$@" --pretty=format:'%T %h %s' \
| while read tree commit subject ; do
    if git ls-tree -r $tree | grep -q "$obj_name" ; then
        echo $commit "$subject"
    fi
done

3
ฉันแค่อยากจะให้เครดิตที่มันครบกำหนด: ขอบคุณความเสียหาย RAM ที่ทำให้ฉัน BSOD และบังคับให้ฉันซ่อมแซม repo คอมไพล์ของฉัน
Mario

4

ดังนั้น ... ฉันต้องการค้นหาไฟล์ทั้งหมดเกินขีด จำกัด ที่กำหนดใน repo ที่มีขนาดมากกว่า 8GB โดยมีการแก้ไขมากกว่า 108,000 ครั้ง ฉันปรับสคริปต์ perl ของอริสโตเติลพร้อมกับสคริปต์ ruby ​​ที่ฉันเขียนเพื่อเข้าถึงโซลูชันที่สมบูรณ์นี้

อันดับแรกgit gc- ทำสิ่งนี้เพื่อให้แน่ใจว่าวัตถุทั้งหมดอยู่ใน packfiles - เราไม่สแกนวัตถุที่ไม่ได้อยู่ในไฟล์ pack

ถัดไปเรียกใช้สคริปต์นี้เพื่อค้นหา blobs ทั้งหมดผ่าน CUTOFF_SIZE ไบต์ จับภาพเอาต์พุตไปยังไฟล์เช่น "large-blobs.log"

#!/usr/bin/env ruby

require 'log4r'

# The output of git verify-pack -v is:
# SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
#
#
GIT_PACKS_RELATIVE_PATH=File.join('.git', 'objects', 'pack', '*.pack')

# 10MB cutoff
CUTOFF_SIZE=1024*1024*10
#CUTOFF_SIZE=1024

begin

  include Log4r
  log = Logger.new 'git-find-large-objects'
  log.level = INFO
  log.outputters = Outputter.stdout

  git_dir = %x[ git rev-parse --show-toplevel ].chomp

  if git_dir.empty?
    log.fatal "ERROR: must be run in a git repository"
    exit 1
  end

  log.debug "Git Dir: '#{git_dir}'"

  pack_files = Dir[File.join(git_dir, GIT_PACKS_RELATIVE_PATH)]
  log.debug "Git Packs: #{pack_files.to_s}"

  # For details on this IO, see http://stackoverflow.com/questions/1154846/continuously-read-from-stdout-of-external-process-in-ruby
  #
  # Short version is, git verify-pack flushes buffers only on line endings, so
  # this works, if it didn't, then we could get partial lines and be sad.

  types = {
    :blob => 1,
    :tree => 1,
    :commit => 1,
  }


  total_count = 0
  counted_objects = 0
  large_objects = []

  IO.popen("git verify-pack -v -- #{pack_files.join(" ")}") do |pipe|
    pipe.each do |line|
      # The output of git verify-pack -v is:
      # SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
      data = line.chomp.split(' ')
      # types are blob, tree, or commit
      # we ignore other lines by looking for that
      next unless types[data[1].to_sym] == 1
      log.info "INPUT_THREAD: Processing object #{data[0]} type #{data[1]} size #{data[2]}"
      hash = {
        :sha1 => data[0],
        :type => data[1],
        :size => data[2].to_i,
      }
      total_count += hash[:size]
      counted_objects += 1
      if hash[:size] > CUTOFF_SIZE
        large_objects.push hash
      end
    end
  end

  log.info "Input complete"

  log.info "Counted #{counted_objects} totalling #{total_count} bytes."

  log.info "Sorting"

  large_objects.sort! { |a,b| b[:size] <=> a[:size] }

  log.info "Sorting complete"

  large_objects.each do |obj|
    log.info "#{obj[:sha1]} #{obj[:type]} #{obj[:size]}"
  end

  exit 0
end

ถัดไปแก้ไขไฟล์เพื่อลบ blobs ใด ๆ ที่คุณไม่ต้องรอและบิต INPUT_THREAD ที่ด้านบน เมื่อคุณมีบรรทัดสำหรับ sha1 เท่านั้นที่คุณต้องการค้นหาให้เรียกใช้สคริปต์ต่อไปนี้เช่นนี้:

cat edited-large-files.log | cut -d' ' -f4 | xargs git-find-blob | tee large-file-paths.log

ตำแหน่งที่git-find-blobสคริปต์อยู่ด้านล่าง

#!/usr/bin/perl

# taken from: http://stackoverflow.com/questions/223678/which-commit-has-this-blob
# and modified by Carl Myers <cmyers@cmyers.org> to scan multiple blobs at once
# Also, modified to keep the discovered filenames
# vi: ft=perl

use 5.008;
use strict;
use Memoize;
use Data::Dumper;


my $BLOBS = {};

MAIN: {

    memoize 'check_tree';

    die "usage: git-find-blob <blob1> <blob2> ... -- [<git-log arguments ...>]\n"
        if not @ARGV;


    while ( @ARGV && $ARGV[0] ne '--' ) {
        my $arg = $ARGV[0];
        #print "Processing argument $arg\n";
        open my $rev_parse, '-|', git => 'rev-parse' => '--verify', $arg or die "Couldn't open pipe to git-rev-parse: $!\n";
        my $obj_name = <$rev_parse>;
        close $rev_parse or die "Couldn't expand passed blob.\n";
        chomp $obj_name;
        #$obj_name eq $ARGV[0] or print "($ARGV[0] expands to $obj_name)\n";
        print "($arg expands to $obj_name)\n";
        $BLOBS->{$obj_name} = $arg;
        shift @ARGV;
    }
    shift @ARGV; # drop the -- if present

    #print "BLOBS: " . Dumper($BLOBS) . "\n";

    foreach my $blob ( keys %{$BLOBS} ) {
        #print "Printing results for blob $blob:\n";

        open my $log, '-|', git => log => @ARGV, '--pretty=format:%T %h %s'
            or die "Couldn't open pipe to git-log: $!\n";

        while ( <$log> ) {
            chomp;
            my ( $tree, $commit, $subject ) = split " ", $_, 3;
            #print "Checking tree $tree\n";
            my $results = check_tree( $tree );

            #print "RESULTS: " . Dumper($results);
            if (%{$results}) {
                print "$commit $subject\n";
                foreach my $blob ( keys %{$results} ) {
                    print "\t" . (join ", ", @{$results->{$blob}}) . "\n";
                }
            }
        }
    }

}


sub check_tree {
    my ( $tree ) = @_;
    #print "Calculating hits for tree $tree\n";

    my @subtree;

    # results = { BLOB => [ FILENAME1 ] }
    my $results = {};
    {
        open my $ls_tree, '-|', git => 'ls-tree' => $tree
            or die "Couldn't open pipe to git-ls-tree: $!\n";

        # example git ls-tree output:
        # 100644 blob 15d408e386400ee58e8695417fbe0f858f3ed424    filaname.txt
        while ( <$ls_tree> ) {
            /\A[0-7]{6} (\S+) (\S+)\s+(.*)/
                or die "unexpected git-ls-tree output";
            #print "Scanning line '$_' tree $2 file $3\n";
            foreach my $blob ( keys %{$BLOBS} ) {
                if ( $2 eq $blob ) {
                    print "Found $blob in $tree:$3\n";
                    push @{$results->{$blob}}, $3;
                }
            }
            push @subtree, [$2, $3] if $1 eq 'tree';
        }
    }

    foreach my $st ( @subtree ) {
        # $st->[0] is tree, $st->[1] is dirname
        my $st_result = check_tree( $st->[0] );
        foreach my $blob ( keys %{$st_result} ) {
            foreach my $filename ( @{$st_result->{$blob}} ) {
                my $path = $st->[1] . '/' . $filename;
                #print "Generating subdir path $path\n";
                push @{$results->{$blob}}, $path;
            }
        }
    }

    #print "Returning results for tree $tree: " . Dumper($results) . "\n\n";
    return $results;
}

ผลลัพธ์จะมีลักษณะดังนี้:

<hash prefix> <oneline log message>
    path/to/file.txt
    path/to/file2.txt
    ...
<hash prefix2> <oneline log msg...>

และอื่น ๆ การคอมมิทที่มีไฟล์ขนาดใหญ่ในแผนผังจะถูกแสดง หากคุณgrepออกจากบรรทัดที่เริ่มต้นด้วยแท็บและuniqคุณจะมีรายการของเส้นทางทั้งหมดที่คุณสามารถกรองสาขาเพื่อลบหรือคุณสามารถทำสิ่งที่ซับซ้อนมากขึ้น

ฉันขอย้ำอีกครั้ง: กระบวนการนี้ทำงานได้สำเร็จบน repo 10GB ที่มี 108,000 คอมมิชชัน มันใช้เวลานานกว่าที่ฉันคาดการณ์ไว้เมื่อวิ่งบน blobs เป็นจำนวนมากแม้ว่านานกว่า 10 ชั่วโมงฉันจะต้องดูว่าบิตท่องจำทำงานได้หรือไม่ ...


1
เช่นเดียวกับคำตอบของอริสโตเติลข้างต้นนี้พบเพียงกระทำในสาขาปัจจุบัน-- --allจนกว่าคุณจะผ่านการขัดแย้งเพิ่มเติม: (การค้นหาการทำธุรกรรมซื้อคืนทั้งหมดนั้นมีความสำคัญในบางกรณีเช่นการลบไฟล์ขนาดใหญ่จากประวัติการซื้อคืนอย่างละเอียด )
peterflynn

4

นอกจากนี้จากการgit describeที่ผมพูดถึงในคำตอบของฉันก่อนหน้า , git logและgit diffตอนนี้ได้รับประโยชน์เช่นกันจาก " --find-object=<object-id>ตัวเลือก" ที่จะ จำกัด ผลการวิจัยไปสู่การเปลี่ยนแปลงที่เกี่ยวข้องกับวัตถุที่มีชื่อ
ที่อยู่ใน Git 2.16.x / 2.17 (Q1 2018)

ดูกระทำ 4d8c51a , กระทำ 5e50525 , กระทำ 15af58c , กระทำ cf63051 , กระทำ c1ddc46 , กระทำ 929ed70 (4 มกราคม 2018) โดยสเตฟานสนั่น (stefanbeller )
(ผสานโดยJunio ​​C Hamano - gitster- in c0d75f0 , 23 Jan 2018)

diffcore: เพิ่มตัวเลือก pickaxe เพื่อค้นหา blob เฉพาะ

บางครั้งผู้ใช้จะได้รับการแฮชของวัตถุและพวกเขาต้องการที่จะระบุเพิ่มเติม (เช่น: ใช้แพ็คตรวจสอบเพื่อค้นหา blobs ที่ใหญ่ที่สุด แต่สิ่งเหล่านี้คืออะไรหรือคำถามกองซ้อนล้น " ซึ่งกระทำนี้มีหยด? ")

บางคนอาจถูกล่อลวงให้ขยายgit-describeเพื่อทำงานร่วมกับ blobs เช่นที่git describe <blob-id>ให้คำอธิบายว่า ':'
สิ่งนี้ถูกนำไปใช้ที่นี่ ; ดังที่เห็นได้จากจำนวนการตอบกลับที่แท้จริง (> 110) มันกลับกลายเป็นว่าเป็นเรื่องยากที่จะพูดถูก
ส่วนที่ยากที่จะทำถูกต้องคือการเลือก 'การกระทำ - อิช' ที่ถูกต้องซึ่งอาจเป็นการกระทำที่ (แนะนำ) แนะนำการหยดหรือการหยดที่เอาหยดออก หยดนั้นมีอยู่ในกิ่งต่าง ๆ

Junio ​​บอกเป็นนัยถึงแนวทางที่แตกต่างในการแก้ปัญหานี้ซึ่งโปรแกรมแก้ไขนี้ใช้
สอนdiffเครื่องจักรให้ใช้ธงอื่นเพื่อ จำกัด ข้อมูลให้ตรงกับที่แสดง
ตัวอย่างเช่น:

$ ./git log --oneline --find-object=v2.0.0:Makefile
  b2feb64 Revert the whole "ask curl-config" topic for now
  47fbfde i18n: only extract comments marked with "TRANSLATORS:"

เราสังเกตว่าMakefileเป็นที่มาพร้อมกับ2.0ได้รับการปรากฏตัวใน และในv1.9.2-471-g47fbfded53 เหตุผลที่ว่าทำไมคอมมิทเหล่านี้เกิดขึ้นก่อนหน้า v2.0.0 นั้นเป็นการรวมที่ชั่วร้ายที่ไม่พบโดยใช้กลไกใหม่นี้v2.0.0-rc1-5-gb2feb6430b

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.