git-fast-export(1)

```mediawiki Mall:manpage

NAMN

git-fast-export - Git-dataexportör

SYNOPSIS

git fast-export [<alternativ>] | git fast-import

BESKRIVNING

Detta program dumpar de givna revisionerna i ett format som är lämpligt att pipas in i git fast-import.

Du kan använda det som en mänskligt läsbar ersättning för bundle (se git-bundle(1)), eller som ett format som kan redigeras innan det matas till git fast-import för att göra om historik (en förmåga som används av verktyg som git filter-repo).

ALTERNATIV

• --progress=<n>

Infoga *progress*-uttryck för varje <n> objekt, som visas av *git

  fast-import* under importen.

• --signed-tags=(verbatim|warn|warn-strip|strip|abort)

Ange hur signerade taggar ska hanteras. Eftersom alla transformationer

  efter exporten kan ändra taggnamnen (vilket också kan hända när
  revisioner exkluderas) kommer signaturerna inte att matcha.

  När du ber om att *abort* (vilket är standard) kommer detta program att
  avslutas när det stöter på en signerad tagg. Med *strip* kommer taggarna
  tyst att göras osignerade, med *warn-strip* kommer de att göras
  osignerade men en varning kommer att visas, med *verbatim* kommer de
  tyst att exporteras och med *warn* kommer de att exporteras, men du
  kommer att se en varning.

• --tag-of-filtered-object=(abort|drop|rewrite)

Ange hur taggar ska hanteras vars taggade objekt filtreras bort.

  Eftersom revisioner och filer som ska exporteras kan begränsas av sökväg
  kan taggade objekt filtreras bort helt.

  När du ber om att *abort* (vilket är standard) kommer detta program att
  avslutas när det stöter på en sådan tagg. Med *drop* kommer den att
  utelämna sådana taggar från utdata. Med *rewrite*, om det taggade
  objektet är en commit, kommer den att skriva om taggen för att tagga en
  förfäderscommit (via föräldraomskrivning; se git-rev-list(1)).

• -M, -C

Utför flytt- och/eller kopieringsdetektering, som beskrivs på

  manualsidan för git-diff(1), och använd den för att generera
  kommandon för omdöpning och kopiering i utdatadumpen.

  Observera att tidigare versioner av detta kommando inte klagade och
  producerade felaktiga resultat om du angav dessa alternativ.

• --export-marks=<fil>

Dumpar den interna markeringstabellen till <fil> när den är klar.

  Markeringar skrivs en per rad som \:markid SHA-1. Endast
  markeringar för revisioner dumpas; markeringar för blobar ignoreras.
  Backend kan använda den här filen för att validera importer efter att de
  har slutförts, eller för att spara markeringstabellen mellan
  inkrementella körningar. Eftersom <fil> endast öppnas och trunkeras vid
  slutförandet kan samma sökväg också säkert anges till --import-marks.
  Filen kommer inte att skrivas om inget nytt objekt har markerats/exporterats.

• --import-marks=<fil>

Innan någon indata bearbetas, ladda de markeringar som anges i <fil>.

  Indatafilen måste finnas, måste vara läsbar och måste använda samma
  format som produceras av --export-marks.

• --mark-tags

Utöver att märka blobar och commits med markerings-ID, märka även

  taggar. Detta är användbart i kombination med --export-marks och
  --import-marks, och är också användbart (och nödvändigt) för
  export av nästade taggar. Det skadar inte andra fall och skulle vara
  standard, men många fast-import-frontend är inte beredda att acceptera
  taggar med markeringsidentifierare.

  Alla commits (eller taggar) som redan har markerats kommer inte att
  exporteras igen. Om backend använder en liknande --import-marks-fil
  möjliggör detta inkrementell dubbelriktad export av repositoryt genom
  att hålla markeringarna desamma mellan körningarna.

• --fake-missing-tagger

Vissa gamla repositoryn har taggar utan taggare. Fast-import-protokollet

  var ganska strikt med det och tillät inte det. Så skapa en falsk taggare
  för att kunna fast-importera utdata.

• --use-done-feature

Starta strömmen med en *feature done*-strof och avsluta den med ett

  *done*-kommando.

• --no-data

Hoppa över utdata av blobobjekt och referera istället till blobar via

  deras ursprungliga SHA-1-hash. Detta är användbart när du skriver om
  katalogstrukturen eller historiken för ett repository utan att röra
  innehållet i enskilda filer. Observera att den resulterande strömmen
  endast kan användas av ett repository som redan innehåller de
  nödvändiga objekten.

• --full-tree

Detta alternativ kommer att få fast-export att utfärda en

  "deleteall"-direktiv för varje commit följt av en fullständig lista över
  alla filer i commiten (i motsats till att bara lista de filer som skiljer
  sig från commitens första förälder).

• --anonymize

Anonymisera innehållet i repositoryt samtidigt som formen på historiken

  och det lagrade trädet bibehålls. Se avsnittet om ANONYMISERING
  nedan.

• --anonymize-map=<från>[:<till>]

Konvertera token <från> till <till> i den anonymiserade utdata. Om

  <till> utelämnas, mappa <från> till sig själv (dvs. anonymisera det
  inte). Se avsnittet om ANONYMISERING nedan.

• --reference-excluded-parents

Som standard kommer körning av ett kommando som git fast-export

  master~5..master inte att inkludera commit master~5 och kommer att
  göra att master~4 inte längre har master~5 som förälder (även om både
  den gamla master~4 och den nya master~4 kommer att ha exakt samma
  filer). Använd --reference-excluded-parents för att istället låta
  strömmen referera till commits i det exkluderade historikintervallet med
  deras sha1sum. Observera att den resulterande strömmen endast kan
  användas av ett repository som redan innehåller de nödvändiga
  föräldracommitarna.

• --show-original-ids

Lägg till ett extra direktiv till utdata för commits och blobar,

  original-oid <SHA1SUM>. Även om sådana direktiv sannolikt kommer
  att ignoreras av importörer som git-fast-import, kan det vara
  användbart för mellanliggande filter (t.ex. för att skriva om
  commitmeddelanden som refererar till äldre commits, eller för att ta
  bort blobar med ID).

• --reencode=(yes|no|abort)

Ange hur *encoding*-huvudet i commitobjekt ska hanteras. När du ber om

  att *abort* (vilket är standard) kommer detta program att avslutas när
  det stöter på ett sådant commitobjekt. Med *yes* kommer commitmeddelandet
  att omkodas till UTF-8. Med *no* kommer den ursprungliga kodningen att
  behållas.

• --refspec

Tillämpa den angivna refspecen på varje exporterad ref. Flera kan

  anges.

• [<git-rev-list-args>...]

En lista med argument, godtagbara för *git rev-parse* och *git

  rev-list*, som anger de specifika objekt och referenser som ska
  exporteras. Till exempel kommer master~10..master att exportera
  den aktuella master-referensen tillsammans med alla objekt som lagts
  till sedan dess tionde förfäderscommit och (om inte alternativet
  --reference-excluded-parents anges) alla filer som är gemensamma för
  master~9 och master~10.

EXEMPEL

```

      $ git fast-export --all | (cd /tomt/repository && git fast-import)

``` Detta exporterar hela repositoryt och importerar det till det befintliga tomma repositoryt. Förutom omkodning av commits som inte är i UTF-8, skulle det vara en en-till-en-spegling. ```

      $ git fast-export master~5..master |
            sed "s|refs/heads/master|refs/heads/other|" |
            git fast-import

``` Detta skapar en ny gren som heter *other* från *master~5..master* (dvs. om

• master* har linjär historik, kommer den att ta de senaste 5 commitarna).

Observera att detta antar att inget av blobarna och commitmeddelandena som refereras av det revisionsintervallet innehåller strängen

• refs/heads/master*.

ANONYMISERING

Om alternativet --anonymize anges kommer git att försöka ta bort all identifierande information från repositoryt samtidigt som tillräckligt av det ursprungliga trädets och historikens mönster bibehålls för att reproducera vissa buggar. Målet är att en git-bugg som hittas i ett privat repository ska finnas kvar i det anonymiserade repositoryt, och det senare kan delas med git-utvecklare för att hjälpa till att lösa buggen.

Med detta alternativ kommer git att ersätta alla refnamn, sökvägar, blobbinnehåll, commit- och taggmeddelanden, namn och e-postadresser i utdata med anonymiserad data. Två instanser av samma sträng kommer att ersättas likvärdigt (t.ex. två commits med samma författare kommer att ha samma anonymiserade författare i utdata, men kommer inte att likna den ursprungliga författarsträngen). Förhållandet mellan commits, grenar och taggar bibehålls, liksom commit-tidsstämplarna (men commitmeddelandena och refnamnen liknar inte originalen). Trädets relativa sammansättning bibehålls (t.ex. om du har ett rotträd med 10 filer och 3 träd, så kommer utdata också att ha det), men deras namn och innehållet i filerna kommer att ersättas.

Om du tror att du har hittat en git-bugg kan du börja med att exportera en anonymiserad ström av hela repositoryt: ```

      $ git fast-export --anonymize --all > anon-stream

``` Bekräfta sedan att buggen kvarstår i ett repository som skapats från den strömmen (många buggar kommer inte att göra det, eftersom de verkligen beror på det exakta repositoryinnehållet): ```

      $ git init anon-repo
      $ cd anon-repo
      $ git fast-import < ../anon-stream
      $ ... testa din bugg ...

``` Om det anonymiserade repositoryt visar buggen kan det vara värt att dela anon-stream tillsammans med en vanlig felrapport. Observera att den anonymiserade strömmen komprimeras mycket bra, så att zippa den rekommenderas. Om du vill undersöka strömmen för att se att den inte innehåller någon privat data kan du granska den direkt innan du skickar. Du kanske också vill prova: ```

      $ perl -pe 's/\d+/X/g' < anon-stream | sort -u | less

``` vilket visar alla unika rader (med siffror konverterade till "X" för att slå ihop "Användare 0", "Användare 1" osv. till "Användare X"). Detta ger en mycket mindre utdata, och det är vanligtvis lätt att snabbt bekräfta att det inte finns någon privat data i strömmen.

Att reproducera vissa buggar kan kräva referenser till specifika commits eller sökvägar, vilket blir utmanande efter att refnamn och sökvägar har anonymiserats. Du kan be om att en viss token ska lämnas oförändrad eller mappas till ett nytt värde. Om du till exempel har en bugg som reproduceras med git rev-list sensitive -- secret.c kan du köra: ```

      $ git fast-export --anonymize --all \
            --anonymize-map=sensitive:foo \
            --anonymize-map=secret.c:bar.c \
            > stream

``` Efter att ha importerat strömmen kan du sedan köra git rev-list foo -- bar.c i det anonymiserade repositoryt.

Observera att sökvägar och refnamn delas upp i tokens vid snedstreck. Kommandot ovan skulle anonymisera subdir/secret.c som något i stil med path123/bar.c; du kan sedan söka efter bar.c i det anonymiserade repositoryt för att bestämma det slutliga sökvägsnamnet.

För att göra det enklare att referera till det slutliga sökvägsnamnet kan du mappa varje sökvägskomponent; så om du också anonymiserar subdir till publicdir skulle det slutliga sökvägsnamnet vara publicdir/bar.c.

BEGRÄNSNINGAR

Eftersom *git fast-import* inte kan tagga träd kommer du inte att kunna exportera linux.git-repositoryt fullständigt, eftersom det innehåller en tagg som refererar till ett träd istället för en commit.

SE ÄVEN

git-fast-import(1)

GIT

Del av git(1)-sviten

KOLOFON

Den här sidan är en del av projektet git (Git distribuerat versionskontrollsystem). Information om projektet finns på <⟨http://git-scm.com/⟩>. Om du har en felrapport för den här manualsidan, se ⟨<http://git-scm.com/community⟩. Den här sidan hämtades från projektets uppströms Git-arkiv <⟨https://github.com/git/git.git⟩> den 2025-02-02. (Vid den tidpunkten var datumet för den senast hittade committen i arkivet 2025-01-31.) Om du upptäcker några renderingsproblem i den här HTML-versionen av sidan, eller om du tror att det finns en bättre eller mer aktuell källa för sidan, eller om du har korrigeringar eller förbättringar av informationen i den här KOLOFONEN (som *inte* är en del av den ursprungliga manualsidan), skicka ett e-postmeddelande till man-pages@man7.org ```

Sidslut

Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-fast-export.1.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp som har sponsrat Linux.se med webbhotell.