¿Qué commit tiene este blob?

Dado el hash de un blob, ¿hay alguna manera de obtener una lista de confirmaciones que tengan este blob en su árbol?

Los siguientes scripts toman el SHA1 del blob como primer argumento, y después, opcionalmente, cualquier argumento que git logcomprenda. Por ejemplo, --allpara buscar en todas las ramas en lugar de solo la actual, o -gpara buscar en el registro, o cualquier otra cosa que desee.

Aquí es como un script de shell: corto y dulce, pero lento:

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

Y una versión optimizada en Perl, todavía bastante corta pero mucho más rápida:

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

Lamentablemente, los guiones fueron un poco lentos para mí, así que tuve que optimizar un poco. Afortunadamente, no solo tenía el hash sino también la ruta de un archivo.

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

Dado el hash de un blob, ¿hay alguna manera de obtener una lista de confirmaciones que tengan este blob en su árbol?

Con Git 2.16 (Q1 2018), git describesería una buena solución, ya que se le enseñó a excavar árboles más profundamente para encontrar uno <commit-ish>:<path>que se refiera a un objeto blob dado.

Consulte commit 644eb60 , commit 4dbc59a , commit cdaed0c , commit c87b653 , commit ce5b6f9 (16 de noviembre de 2017) y commit 91904f5 , commit 2deda00 (02 de noviembre de 2017) por Stefan Beller ( stefanbeller) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 556de1a , 28 dic 2017)}

builtin/describe.c: describe una gota

A veces, los usuarios reciben un hash de un objeto y desean identificarlo más a fondo (por ejemplo: usar verify-packpara encontrar los blobs más grandes, pero ¿qué son estos? O esta pregunta SO " ¿Qué commit tiene este blob? ")

Cuando describimos commits, tratamos de anclarlos a etiquetas o referencias, ya que estos están conceptualmente en un nivel más alto que el commit. Y si no hay una referencia o etiqueta que coincida exactamente, no tenemos suerte.
Entonces, empleamos una heurística para inventar un nombre para el commit. Estos nombres son ambiguos, puede haber diferentes etiquetas o referencias a las que anclar, y puede haber una ruta diferente en el DAG para viajar para llegar al compromiso con precisión.

Al describir un blob, también queremos describir el blob desde una capa superior, que es una tupla de (commit, deep/path)que los objetos del árbol involucrados son bastante poco interesantes.
El mismo blob puede ser referenciado por múltiples commits, entonces, ¿cómo decidimos qué commit usar?

Este parche implementa un enfoque bastante ingenuo al respecto: dado que no hay punteros hacia atrás desde los blobs hasta los commits en los que se produce el blob, comenzaremos a caminar a partir de cualquier consejo disponible, enumerando los blobs en el orden del commit y una vez que encontramos el blob, tomaremos la primera confirmación que enumeró el blob .

Por ejemplo:

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

nos dice que Makefiletal como estaba v0.99se introdujo en commit 7672db2 .

La caminata se realiza en orden inverso para mostrar la introducción de una gota en lugar de su última aparición.

Eso significa que la git describepágina del manual se suma a los propósitos de este comando:

En lugar de simplemente describir una confirmación utilizando la etiqueta más reciente a la que se puede acceder, en git describerealidad le dará a un objeto un nombre legible para humanos basado en una referencia disponible cuando se use como git describe <blob>.

Si el objeto dado se refiere a un blob, se describirá como <commit-ish>:<path>tal, que el blob se puede encontrar <path>en <commit-ish>, que describe la primera confirmación en la que este blob se produce en una caminata de revisión inversa desde HEAD.

Pero:

LOCO

Los objetos de árbol, así como los objetos de etiqueta que no apuntan a confirmaciones, no se pueden describir .
Al describir los blobs, las etiquetas livianas que apuntan a los blobs se ignoran, pero el blob todavía se describe a <committ-ish>:<path>pesar de que la etiqueta liviana es favorable.

Pensé que esto sería algo generalmente útil, así que escribí un pequeño script en perl para hacerlo:

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

Pondré esto en Github cuando llegue a casa esta noche.

Actualización: Parece que alguien ya hizo esto . Ese usa la misma idea general pero los detalles son diferentes y la implementación es mucho más corta. ¡No sé cuál sería más rápido, pero el rendimiento probablemente no sea una preocupación aquí!

Actualización 2: por lo que vale, mi implementación es mucho más rápida, especialmente para un gran repositorio. Eso git ls-tree -rrealmente duele.

Actualización 3: debo tener en cuenta que mis comentarios de rendimiento anteriores se aplican a la implementación que vinculé anteriormente en la primera actualización. La implementación de Aristóteles es comparable a la mía. Más detalles en los comentarios para aquellos que tienen curiosidad.

Si bien la pregunta original no lo solicita, creo que es útil verificar también el área de preparación para ver si se hace referencia a un blob. Modifiqué el script bash original para hacer esto y encontré lo que hacía referencia a un blob corrupto en mi repositorio:

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

Entonces ... necesitaba encontrar todos los archivos por encima de un límite dado en un repositorio de más de 8GB de tamaño, con más de 108,000 revisiones. Adapté el guión perl de Aristóteles junto con un guión rubí que escribí para llegar a esta solución completa.

Primero, git gchaga esto para asegurarse de que todos los objetos estén en paquetes de archivos, no escaneamos objetos que no estén en archivos de paquetes.

A continuación, ejecute este script para localizar todos los blobs en CUTOFF_SIZE bytes. Capture la salida a un archivo como "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

A continuación, edite el archivo para eliminar cualquier blob que no espere y los bits INPUT_THREAD en la parte superior. una vez que tenga solo líneas para los sha1 que desea encontrar, ejecute el siguiente script de esta manera:

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

Donde el git-find-blobguión está abajo.

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

La salida se verá así:

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

Y así. Se enumerará cada confirmación que contenga un archivo grande en su árbol. Si grepsale de las líneas que comienzan con una pestaña, y uniqasí, tendrá una lista de todas las rutas que puede filtrar-ramificar para eliminar, o puede hacer algo más complicado.

Permítanme reiterar: este proceso se ejecutó con éxito, en un repositorio de 10GB con 108,000 confirmaciones. Tomó mucho más tiempo de lo que predije cuando se ejecutó en una gran cantidad de blobs, sin embargo, durante 10 horas, tendré que ver si el bit de memorización está funcionando ...

Además de git describeeso, lo menciono en mi respuesta anterior , git logy git diffahora también se beneficia de la --find-object=<object-id>opción " " para limitar los hallazgos a los cambios que involucran el objeto nombrado.
Eso está en Git 2.16.x / 2.17 (Q1 2018)

Ver commit 4d8c51a , commit 5e50525 , commit 15af58c , commit cf63051 , commit c1ddc46 , commit 929ed70 (04 de enero de 2018) por Stefan Beller ( stefanbeller) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit c0d75f0 , 23 ene 2018)}

diffcore: agrega una opción de pico para encontrar un blob específico

A veces, los usuarios reciben un hash de un objeto y desean identificarlo más a fondo (por ejemplo: Use allow-pack para encontrar los blobs más grandes, pero ¿qué son estos? O esta pregunta de Stack Overflow " ¿Qué commit tiene este blob? ")

Uno podría verse tentado a extenderse git-describepara trabajar también con blobs, de modo que se git describe <blob-id>dé una descripción como ':'
Esto fue implementado aquí ; Como se ve por la gran cantidad de respuestas (> 110), resulta que es difícil acertar.
La parte difícil de acertar es elegir el 'commit-ish' correcto, ya que podría ser el commit que (re) introdujo el blob o el blob que eliminó el blob; la gota podría existir en diferentes ramas.

Junio ​​insinuó un enfoque diferente para resolver este problema, que implementa este parche.
Enseñe a la diffmaquinaria otra bandera para restringir la información a lo que se muestra.
Por ejemplo:

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

Observamos que el Makefilecomo enviado con 2.0apareció en v1.9.2-471-g47fbfded53y en v2.0.0-rc1-5-gb2feb6430b.
La razón por la cual estos commits ocurren antes de v2.0.0 son fusiones malignas que no se encuentran utilizando este nuevo mecanismo.