Bu blobun hangi kaydı var?


155

Bir blobun karması verildiğinde, ağacında bu blob bulunan commit'lerin bir listesini almanın bir yolu var mı?


2
"Bir blobun karması", yalnızca blob içeriğinin sha1 toplamı değil, git hash-objectveya tarafından döndürülendir sha1("blob " + filesize + "\0" + data).
Ivan Hamilton

1
Başlangıçta bu sorunun sorumla eşleştiğini düşünmüştüm, ancak öyle görünmüyor. Bilmek istiyorum bir ilki taahhüt tanıtılan deposuna bu blob.
Jesse Glick

Dosya git log --follow filepathyolunu biliyorsanız (ve isterseniz bunu Aristoteles'in çözümünü hızlandırmak için kullanabilirsiniz).
Zaz

ProTip ™: Aşağıdaki komut dosyalarından birini koyun ~/.binve adlandırın git-find-object. Daha sonra ile kullanabilirsiniz git find-object.
Zaz

1
Not: Git 2.16 (Q1 2018) ile şunları düşünebilirsiniz git describe <hash>: Aşağıdaki cevabıma bakın .
VonC

Yanıtlar:


109

Aşağıdaki komut dosyalarının her ikisi de blob'un SHA1'ini ilk argüman olarak ve ondan sonra isteğe bağlı olarak git loganlayacak herhangi bir argümanı alır . Örneğin --all, sadece mevcut şube yerine tüm şubelerde -garama yapmak veya reflog'da ya da başka ne isterseniz aramak.

İşte bir kabuk betiği gibi - kısa ve tatlı ama yavaş:

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

Ve Perl'de optimize edilmiş bir sürüm, yine de oldukça kısa ama çok daha hızlı:

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

9
Bilginize, blob'un tam SHA'sını kullanmanız gerekir. Bir önek, benzersiz olsa bile çalışmayacaktır. Tam SHA'yı bir önekten almak için kullanabilirsinizgit rev-parse --verify $theprefix
John Douthat

1
Bu yorum için teşekkürler @JohnDouthat. Bunu yukarıdaki senaryoya nasıl dahil edeceğiniz aşağıda açıklanmıştır (yorumlardaki satır içi yazım için özür dilerim): 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

Üst kabuk komut dosyasında hata olabilir. While döngüsü sadece okunacak daha fazla satır varsa ve her ne sebeple olursa olsun git log uca son bir crlf koymuyorsa çalıştırılır. Bir satır besleme eklemem ve boş satırları görmezden gelmem gerekiyordu. 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
Bu , ek bir bağımsız değişken olarak geçmediğiniz sürece yalnızca geçerli daldaki commit'leri bulur --all. ( Depo geçmişinden büyük bir dosyanın silinmesi gibi durumlarda repo genelinde tüm commit'leri bulmak önemlidir ).
peterflynn

1
İpucu: reflog'u incelemek için -g bayrağını kabuk betiğine (nesne kimliğinden sonra) iletin.
Bram Schoenmakers

24

Ne yazık ki komut dosyaları benim için biraz yavaştı, bu yüzden biraz optimize etmem gerekti. Neyse ki sadece hash değil, aynı zamanda bir dosyanın yolu da vardı.

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

1
Mükemmel cevap çünkü çok basit. Sadece yolun bilindiğine dair makul bir varsayımda bulunarak. Bununla birlikte, yolun verilen karma olarak değiştirildiği kaydı döndürdüğü bilinmelidir.
Unapiedra

1
Biri en yeni istiyorsa içeren taahhüt <hash>verilen <path>, daha sonra kaldırarak <path>gelen argüman git logirade çalışmaları. İlk döndürülen sonuç, istenen kaydetmedir.
Unapiedra

10

Bir blobun karması verildiğinde, ağacında bu blob bulunan commit'lerin bir listesini almanın bir yolu var mı?

Git 2.16 (Q1 2018) ile, belirli bir blob nesnesine atıfta bulunan bir nesneyi git describebulmak için ağaçları daha derine kazması öğretildiği için iyi bir çözüm olabilir <commit-ish>:<path>.

Bkz 644eb60 işlemek , 4dbc59a işlemek , cdaed0c işlemek , c87b653 işlemek , ce5b6f9 taahhüt (16 Kasım 2017) ve 91904f5 taahhüt , 2deda00 taahhüt tarafından (02 Kas 2017) Stefan Beller'in ( stefanbeller) .
(Göre Birleştirilmiş Junio Cı Hamano - gitster- içinde 556de1a tamamlama 2017 28 Ara)

builtin/describe.c: bir blob tanımlama

Bazen kullanıcılar bir nesnenin bir karma verilir ve onlar daha da tanımlamak istediğiniz (örn .: Kullanım verify-packbüyük lekeler bulmak için, ama bunlar? Ya bu çok SO soru nelerdir " Bu damla vardır taahhüt? ")

Kaydetmeyi açıklarken, bunları kavramsal olarak commit'den daha yüksek bir seviyede oldukları için etiketlere veya referanslara sabitlemeye çalışırız. Ve tam olarak eşleşen herhangi bir ref veya etiket yoksa, şansımız yok.
Bu nedenle, commit için bir isim oluşturmak için bir buluşsal yöntem kullanırız. Bu adlar belirsizdir, farklı etiketler veya referanslar olabilir ve kesin olarak işleme ulaşmak için DAG'de gidilecek farklı yollar olabilir.

Bir blobu açıklarken, blob'u daha yüksek bir katmandan da tanımlamak istiyoruz, bu, (commit, deep/path)ilgili ağaç nesnelerinin oldukça ilgi çekici olmadığı için bir demettir.
Aynı blob birden fazla kaydetme ile referans gösterilebilir, peki hangi kaydetmeyi kullanacağımıza nasıl karar veririz?

Bu yama, bu konuda oldukça naif bir yaklaşım uygular: Bloblardan, blobun gerçekleştiği işlemlere kadar hiçbir geri işaretçi olmadığından, mevcut tüm ipuçlarından yürümeye başlayacağız, blobları commit sırasına göre listeleyeceğiz ve bulduğumuzda blob, blob'u listeleyen ilk commit'i alacağız .

Örneğin:

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

söyler Makefileiçeri gibi v0.99tanıtıldı 7672db2 taahhüt .

Yürüme, bir blobun son oluşumundan ziyade girişini göstermek için ters sırada gerçekleştirilir.

Bu, git describeman sayfasının bu komutun amaçlarına katkıda bulunduğu anlamına gelir :

Basitçe ondan ulaşılabilen en son etiketi kullanarak bir kaydetmeyi tanımlamak yerine, git describeaslında bir nesneye, olarak kullanıldığında mevcut bir ref temelinde okunabilir bir ad verir git describe <blob>.

Belirli bir nesne bir damla değinmektedir, şekilde tarif edilecektir <commit-ish>:<path>damla bulunabilir, öyle ki, <path>içinde <commit-ish>kendini ilk olarak bu leke kafasından ters bir revizyon yürüyüş mesafesinde meydana geldiği tamamlama tanımlayan.

Fakat:

HATALAR

Ağaç nesneleri ve kaydetmeye işaret etmeyen etiket nesneleri tanımlanamaz .
Blobları açıklarken, bloblara işaret eden hafif etiketler göz ardı edilir, ancak blob, <committ-ish>:<path>hafif etiketin olumlu olmasına rağmen yine de tanımlanır .


2
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 20Size en büyük 20 blob'u döndüren, birlikte kullanmak iyidir. Sonra yukarıdaki çıktıdan blob kimliğini git describe. Büyüleyici oldu! Teşekkürler!
Alexander Pogrebnyak

7

Bunun genellikle yararlı bir şey olacağını düşündüm, bu yüzden bunu yapmak için küçük bir perl betiği yazdım:

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

Bu akşam eve geldiğimde bunu github'a koyacağım.

Güncelleme: Görünüşe göre birisi bunu zaten yapmış . Bu aynı genel fikri kullanıyor ancak ayrıntılar farklı ve uygulama çok daha kısa. Hangisinin daha hızlı olacağını bilmiyorum ama performans muhtemelen burada bir sorun değil!

Güncelleme 2: Değeri ne olursa olsun, benim uygulamam, özellikle büyük bir havuz için daha hızlıdır. Bu git ls-tree -rgerçekten acıtıyor.

Güncelleme 3: Yukarıdaki performans yorumlarımın, yukarıda ilk Güncellemede bağlantı kurduğum uygulama için geçerli olduğunu unutmamalıyım. Aristoteles'in uygulaması benimkine benzer bir performans sergiliyor. Merak edenler için yorumlarda daha fazla detay.


Hmm, nasıl bu kadar hızlı olabilir? Yine de ağacı yürüyorsun, değil mi? Git-ls-tree kaçındığınız iş nedir? (Not: grep, git-ls ağacını SIGPIPE ile ilk maçta kurtaracak.) Bunu denediğimde, betiğinizi 30 saniye sonra Ctrl-C'ye bıraktım; benimki 4'te yapıldı.
Aristotle Pagaltzis

1
Betiğim, alt ağaçların sonuçlarını% ağaç hash'inde önbelleğe alır, bu nedenle değişmemiş alt ağaçları aramaya devam etmek zorunda kalmaz.
Greg Hewgill

Aslında bağlantı kurduğum github'da bulduğum uygulamayı deniyordum. Sizinki bazı durumlarda daha hızlıdır, ancak büyük ölçüde aradığınız dosyanın ls-tree listesinin başında mı yoksa sonunda mı olduğuna bağlıdır. Depomda şu anda 9574 dosya var.
Greg Hewgill

Bazı doğrusal olmayan proje geçmişlerinin betiğimin gerekenden çok daha fazla iş yapmasına neden olabileceği de aklıma geliyor (bu düzeltilebilir). Bu yüzden senin için koşmak uzun zaman aldı. Benim havuzum bir Subversion deposunun git-svn aynasıdır, bu yüzden oldukça doğrusaldır.
Greg Hewgill

Ağacı elde etmek için kedi dosyasını ayrıştırmak yerine sadece yapıngit rev-parse $commit^{}
jthill

6

Orijinal soru sormasa da, bir blobun referans alınıp alınmadığını görmek için evreleme alanını da kontrol etmenin yararlı olacağını düşünüyorum. Bunu yapmak için orijinal bash komut dosyasını değiştirdim ve depomda bozuk bir blob'a referans veren şeyi buldum:

#!/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
Sadece gerektiği yerde kredi vermek istiyorum: bana bir BSOD'ye neden olduğu ve git depomu elden tamir etmeye zorladığı için RAM bozulmasına teşekkür ederim.
Mario

6

Ek olarak git describebenim önceki yanıtta söyleyince , git logve git diffşimdi "dan da yararına --find-object=<object-id>adındaki nesneyi içeren değişikliklere bulguları sınırlamak için" seçeneği.
Bu Git 2.16.x / 2.17'de (2018 1. Çeyrek)

Bkz 4d8c51a işlemek , 5e50525 taahhüt , 15af58c işlemek , cf63051 işlemek , c1ddc46 işlemek , 929ed70 taahhüt tarafından (04 Oca 2018) Stefan Beller'in ( stefanbeller) .
( Junio ​​C Hamano ile birleştirildi - gitster- in commit c0d75f0 , 23 Ocak 2018)

diffcore: belirli bir damla bulmak için bir kazma seçeneği ekleyin

Bazen kullanıcılara bir nesnenin karması verilir ve onu daha fazla tanımlamak isterler (ör. En büyük blobları bulmak için doğrulama paketini kullanın, ancak bunlar nedir? Veya bu Yığın Taşma sorusu " Bu blobun hangisi var? ")

":" git-describeŞeklinde git describe <blob-id>bir açıklama verecek şekilde bloblarla çalışmak için genişletmek cazip gelebilir .
Bu burada uygulandı ; Çok sayıdaki yanıttan (> 110) görüldüğü gibi, bunu doğru yapmanın zor olduğu ortaya çıkıyor.
Doğru yapmanın zor kısmı, blobu veya blobu kaldıran blobu (yeniden) tanıtan kesinleştirme olabileceği için doğru 'commit-ish'i seçmektir; blob farklı dallarda var olabilir.

Junio, bu düzeltme ekinin uyguladığı, bu sorunu çözmek için farklı bir yaklaşıma işaret etti.
Makineye, diffbilgileri gösterilenle sınırlandırmak için başka bir bayrak öğretin .
Örneğin:

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

Makefileile birlikte gönderilenlerin içeri ve içinde 2.0göründüğünü görüyoruz . Her ikisinin de v2.0.0'dan önce gerçekleşmesinin nedeni, bu yeni mekanizma kullanılarak bulunmayan kötü birleştirmelerdir.v1.9.2-471-g47fbfded53v2.0.0-rc1-5-gb2feb6430b


4

Bu yüzden ... 8GB üzerindeki bir depoda, 108.000'den fazla revizyon ile belirli bir sınırın üzerindeki tüm dosyaları bulmam gerekiyordu. Bu eksiksiz çözüme ulaşmak için yazdığım bir Ruby senaryosuyla birlikte Aristoteles'in perl senaryosunu uyarladım.

Öncelikle, git gc- tüm nesnelerin paket dosyalarında olduğundan emin olmak için bunu yapın - paket dosyalarında olmayan nesneleri taramayız.

Sonraki CUTOFF_SIZE bayt üzerindeki tüm blobları bulmak için bu komut dosyasını çalıştırın. Çıktıyı "büyük blobs.log" gibi bir dosyaya yakalayın

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

Ardından, beklemediğiniz tüm lekeleri ve üstteki INPUT_THREAD bitlerini kaldırmak için dosyayı düzenleyin. Sadece bulmak istediğiniz sha1'ler için satırınız olduğunda, aşağıdaki komut dosyasını şu şekilde çalıştırın:

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

git-find-blobKomut dosyası aşağıda nerede .

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

Çıktı şöyle görünecek:

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

Ve bunun gibi. Ağacında büyük bir dosya içeren her işlem listelenecektir. grepBir sekmeyle başlayan satırların dışında kalırsanız ve uniqbunun için, filtreleyerek dallara ayırabileceğiniz tüm yolların bir listesine sahip olursunuz veya daha karmaşık bir şey yapabilirsiniz.

Tekrar belirteyim: bu süreç 108.000 taahhütle 10GB'lık bir depoda başarılı bir şekilde yürütüldü. Çok sayıda blob üzerinde çalışırken tahmin ettiğimden çok daha uzun sürdü, ancak 10 saatten fazla, ezberleme bitinin çalışıp çalışmadığını görmem gerekecek ...


1
Yukarıdaki Aristoteles'in cevap gibi, bu sadece kaydedilmesini bulur geçerli dal üzerinde ek argümanlar geçmedikçe: -- --all. ( Depo geçmişinden büyük bir dosyanın tamamen silinmesi gibi durumlarda depo genelinde tüm taahhütleri bulmak önemlidir ).
peterflynn
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.