Który commit ma ten blob?

Biorąc pod uwagę skrót obiektu blob, czy istnieje sposób na uzyskanie listy zatwierdzeń, które mają ten obiekt blob w swoim drzewie?

Oba poniższe skrypty przyjmują wartość SHA1 obiektu BLOB jako pierwszy argument, a po nim opcjonalnie wszystkie git logzrozumiałe argumenty . Na przykład, --allaby przeszukać wszystkie gałęzie zamiast tylko bieżącej, lub -gprzeszukać reflog, lub cokolwiek innego, co chcesz.

Oto skrypt powłoki - krótki i słodki, ale powolny:

#!/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

I zoptymalizowana wersja w Perlu, wciąż dość krótka, ale znacznie szybsza:

#!/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 );
}

Niestety skrypty były dla mnie trochę powolne, więc musiałem trochę zoptymalizować. Na szczęście miałem nie tylko hash, ale także ścieżkę do pliku.

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

Biorąc pod uwagę skrót obiektu blob, czy istnieje sposób na uzyskanie listy zatwierdzeń, które mają ten obiekt blob w swoim drzewie?

Z Git 2.16 (Q1 2018) git describebyłoby dobrym rozwiązaniem, ponieważ nauczono go kopać głębiej drzewa, aby znaleźć obiekt, <commit-ish>:<path>który odnosi się do danego obiektu typu blob.

Zobacz zatwierdzenie 644eb60 , zatwierdzenie 4dbc59a , zatwierdzenie cdaed0c , zatwierdzenie c87b653 , zatwierdzenie ce5b6f9 (16 listopada 2017) i zatwierdzenie 91904f5 , zatwierdzenie 2deda00 (02 listopada 2017) autorstwa Stefana Bellera ( stefanbeller) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 556de1a , 28 grudnia 2017)}

builtin/describe.c: opisz kroplę

Czasami użytkownicy otrzymują skrót obiektu i chcą go dokładniej zidentyfikować (np .: Użyj, verify-packaby znaleźć największe obiekty blob, ale co to jest? Lub to bardzo TAK pytanie „ Które zatwierdzenie ma ten obiekt blob? ”)

Podczas opisywania zatwierdzeń staramy się zakotwiczyć je w tagach lub odnośnikach, ponieważ są one koncepcyjnie na wyższym poziomie niż zatwierdzenie. A jeśli nie ma ref lub tagu, który dokładnie pasuje, nie mamy szczęścia.
Dlatego stosujemy heurystykę, aby nadać nazwę zatwierdzeniu. Nazwy te są niejednoznaczne, mogą istnieć różne tagi lub odniesienia do zakotwiczenia, a w DAG może istnieć inna ścieżka, którą należy podróżować, aby precyzyjnie dotrzeć do zatwierdzenia.

Opisując obiekt blob, chcemy również opisać go z wyższej warstwy, co jest krotką, (commit, deep/path)ponieważ obiekty drzewa, których to dotyczy, są raczej nieinteresujące.
Do tego samego obiektu blob może się odwoływać wiele zatwierdzeń, więc jak zdecydujemy, którego zatwierdzenia użyć?

Ta łatka implementuje raczej naiwne podejście do tego: ponieważ nie ma wskaźników wstecz od plamek do zatwierdzeń, w których występuje blob, zaczniemy chodzić od wszelkich dostępnych wskazówek, wymieniając obiekty w kolejności zatwierdzenia i gdy znajdziemy blob, weźmiemy pierwsze zatwierdzenie, które zawierało ten obiekt .

Na przykład:

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

mówi nam, że Makefiletak jak było, v0.99zostało wprowadzone w zatwierdzeniu 7672db2 .

Spacer jest wykonywany w odwrotnej kolejności, aby pokazać wprowadzenie kropki, a nie jej ostatnie wystąpienie.

Oznacza to, że git describestrona podręcznika dodaje do celów tego polecenia:

Zamiast po prostu opisywać zatwierdzenie za pomocą najnowszego dostępnego z niego znacznika, w git describerzeczywistości nada obiektowi czytelną dla człowieka nazwę na podstawie dostępnego ref, gdy jest używany jako git describe <blob>.

Jeżeli dany obiekt odnosi się kropelka zostanie on opisany jako <commit-ish>:<path>tak, że kropelka można znaleźć w <path>w <commit-ish>, które z kolei opisano w którym pierwszy popełnić to nastąpi blob w odwrotnej zmiany odległości od głowy.

Ale:

ROBAKI

Nie można opisać obiektów drzewiastych ani obiektów znaczników, które nie wskazują na zatwierdzenia .
Podczas opisywania obiektów blob lekkie znaczniki wskazujące na obiekty blob są ignorowane, ale obiekt BLOB jest nadal opisywany jako <committ-ish>:<path>pomimo tego, że lekki znacznik jest korzystny.

Pomyślałem, że byłoby to ogólnie przydatne, więc napisałem mały skrypt w Perlu, aby to zrobić:

#!/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);
}

Umieszczę to na githubie, kiedy wrócę do domu wieczorem.

Aktualizacja: Wygląda na to, że ktoś już to zrobił . Ten używa tego samego ogólnego pomysłu, ale szczegóły są inne, a implementacja jest znacznie krótsza. Nie wiem, co byłoby szybsze, ale wydajność prawdopodobnie nie jest tutaj problemem!

Aktualizacja 2: Bez względu na to, co jest warte, moja implementacja jest szybsza o rząd wielkości, szczególnie w przypadku dużego repozytorium. To git ls-tree -rnaprawdę boli.

Aktualizacja 3: Należy zauważyć, że moje uwagi dotyczące wydajności powyżej odnoszą się do implementacji, do której dołączyłem powyżej w pierwszej aktualizacji. Realizacja Arystotelesa działa porównywalnie z moją. Więcej szczegółów w komentarzach dla ciekawskich.

Chociaż pierwotne pytanie o to nie pyta, myślę, że warto również sprawdzić obszar przemieszczania, aby zobaczyć, czy odwołuje się do obiektu blob. Zmodyfikowałem oryginalny skrypt basha, aby to zrobić, i znalazłem odwołanie do uszkodzonego obiektu blob w moim repozytorium:

#!/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

Więc ... Musiałem znaleźć wszystkie pliki przekraczające podany limit w repozytorium o rozmiarze ponad 8 GB, z ponad 108 000 wersji. Zaadaptowałem skrypt Perla Arystotelesa wraz ze skryptem rubinowym, który napisałem, aby osiągnąć to kompletne rozwiązanie.

Po pierwsze git gc- zrób to, aby upewnić się, że wszystkie obiekty znajdują się w plikach paczek - nie skanujemy obiektów, których nie ma w plikach paczek.

Następnie Uruchom ten skrypt, aby zlokalizować wszystkie obiekty blob w bajtach CUTOFF_SIZE. Przechwyć dane wyjściowe do pliku takiego jak „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

Następnie edytuj plik, aby usunąć wszystkie obiekty blob, na które nie czekasz, i bity INPUT_THREAD u góry. kiedy masz już tylko linie dla sha1, które chcesz znaleźć, uruchom następujący skrypt w ten sposób:

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

Gdzie git-find-blobskrypt jest poniżej.

#!/usr/bin/perl

# taken from: http://stackoverflow.com/questions/223678/which-commit-has-this-blob
# and modified by Carl Myers <[email protected]> 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;
}

Wynik będzie wyglądał następująco:

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

I tak dalej. Wyświetlone zostanie każde zatwierdzenie zawierające duży plik w swoim drzewie. jeśli usuniesz greplinie zaczynające się od tabulatora, uniqbędziesz mieć listę wszystkich ścieżek, które możesz usunąć za pomocą filtra lub możesz zrobić coś bardziej skomplikowanego.

Powtórzę: ten proces przebiegał pomyślnie na repozytorium 10 GB ze 108 000 zatwierdzeń. Trwało to znacznie dłużej niż przewidywałem, gdy działałem na dużej liczbie plamek, ale ponad 10 godzin będę musiał sprawdzić, czy zapamiętywanie działa ...

Ponadto git describewspomniałem o tym w mojej poprzedniej odpowiedzi , git loga git diffteraz również korzysta z opcji „ --find-object=<object-id>” ograniczającej wyniki do zmian dotyczących nazwanego obiektu.
To jest w Git 2.16.x / 2.17 (Q1 2018)

Zobacz commit 4d8c51a , commit 5e50525 , commit 15af58c , commit cf63051 , commit c1ddc46 , commit 929ed70 (4 stycznia 2018) autor: Stefan Beller ( stefanbeller) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu c0d75f0 , 23 stycznia 2018 r.)}

diffcore: dodaj opcję kilofa, aby znaleźć konkretną kroplę

Czasami użytkownicy otrzymują skrót obiektu i chcą go dokładniej zidentyfikować (np .: użyj pakietu weryfikacji, aby znaleźć największe obiekty blob, ale co to jest? Lub pytanie „ Które zatwierdzenie ma ten obiekt blob? ”)

Można ulec pokusie, aby rozszerzyć git-describepracę również z obiektami blob, które git describe <blob-id>dają opis jako „:”.
Zostało to zaimplementowane tutaj ; jak widać po samej liczbie odpowiedzi (> 110), okazuje się, że jest to trudne do uzyskania.
Najtrudniej jest wybrać poprawne „zatwierdzenie”, ponieważ może to być zatwierdzenie, które (ponownie) wprowadziło obiekt BLOB lub BLOB, który usunął obiekt BLOB; kropelka może istnieć w różnych gałęziach.

Junio ​​zasugerował inne podejście do rozwiązania tego problemu, które implementuje ta łatka.
Naucz diffmaszynę kolejnej flagi, aby ograniczyć informacje do tego, co jest pokazane.
Na przykład:

$ ./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:"

obserwujemy, że produkt, z Makefilektórym 2.0został dostarczony, pojawił się v1.9.2-471-g47fbfded53w v2.0.0-rc1-5-gb2feb6430b.
Powodem, dla którego oba te zatwierdzenia występują przed wersją 2.0.0, są złe połączenia, których nie można znaleźć przy użyciu tego nowego mechanizmu.