Atskirti (perkelti) antrinį katalogą į atskirą „Git“ saugyklą

Turiu „ Git“ saugyklą, kurioje yra keletas pakatalogių. Dabar pastebėjau, kad vienas iš pakatalogių nėra susijęs su kitu ir turėtų būti atskirtas nuo atskiro saugyklos.

Kaip tai padaryti, išsaugant failo istoriją pakatalogyje?

Manau, kad galėčiau padaryti kloną ir pašalinti nepageidaujamą kiekvieno klono dalį, bet manau, kad jis suteiks man pilną medį, kai patikriname senesnę versiją ir tt Tai gali būti priimtina, bet norėčiau apsimesti, kad dvi saugyklos neturi bendros istorijos.

Kad tai būtų aišku, turiu tokią struktūrą:

 XYZ/ .git/ XY1/ ABC/ XY2/ 

Bet aš to norėčiau:

 XYZ/ .git/ XY1/ XY2/ ABC/ .git/ ABC/ 
1628
11 дек. set matli 11 gruodis 2008-12-11 16:57 '08, 4:57 2008-12-11 16:57
@ 23 atsakymai

Atnaujinimas : šis procesas yra toks dažnas, kad naujojo įrankio, „ git subtree “, git komanda tapo daug lengvesnė. Žr. Čia: Pakatalogis Atskirti (perkelti) atskiroje „Git“ saugykloje


Norite klonuoti savo saugyklą ir tada naudokite „ git filter-branch kad pažymėtumėte viską, išskyrus antrinį katalogą, kurį norite naujoje repo rinkti šiukšles.

  1. Jei norite klonuoti vietinę saugyklą:

     git clone /XYZ /ABC 

    (Pastaba: kapinynas bus klonuojamas naudojant 1 kietąjį rašalą, tačiau tai nėra problema, nes sunkūs -l failai su rašalu nebus pakeisti - nauji bus sukurti).

  2. Dabar leiskite išsaugoti įdomias šakas, kurias taip pat norime perrašyti, ir tada ištrinti šaltinį, kad nespustelėkite, ir įsitikinkite, kad senieji įsipareigojimai nebus susiję su kilme:

     cd /ABC for i in branch1 br2 br3; do git branch -t $i origin/$i; done git remote rm origin 

    arba visiems nuotoliniams filialams:

     cd /ABC for i in $(git branch -r | sed "s/.*origin\///"); do git branch -t $i origin/$i; done git remote rm origin 
  3. Dabar taip pat galite pašalinti žymes, nesusijusias su subprojektu; Taip pat galite tai padaryti vėliau, tačiau gali prireikti sumažinti atpirkimo laiką. Aš to nepadariau ir gavau WARNING: Ref 'refs/tags/v0.1' is unchanged visoms žymėms WARNING: Ref 'refs/tags/v0.1' is unchanged (nes visi jie nėra susiję su subprojektu); Be to, pašalinus tokias žymes, bus nustatyta daugiau vietos. Akivaizdu, kad „ git filter-branch turėtų galėti perrašyti kitas žymes, tačiau negalėjau jo patikrinti. Jei norite pašalinti visas žymes, naudokite git tag -l | xargs git tag -d git tag -l | xargs git tag -d git tag -l | xargs git tag -d git tag -l | xargs git tag -d .

  4. Tada naudokite filtro šaką ir išmeskite jį, kad pašalintumėte kitus failus, kad jie būtų sutrumpinti. Leiskite taip pat pridėti --tag-name-filter cat --prune-empty kad pašalintumėte tuščius įsipareigojimus ir --tag-name-filter cat --prune-empty žymes (atkreipkite dėmesį, kad tai turės būti --tag-name-filter cat --prune-empty jų parašu):

     git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter ABC -- --all 

    arba, tiesiog perrašykite HEAD filialą ir ignoruokite žymes ir kitus filialus:

     git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter ABC HEAD 
  5. Tada ištrinkite atsargines žurnalo rinkmenas taip, kad erdvė būtų tikrai suremontuota (nors dabar operacija yra žalinga)

     git reset --hard git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d git reflog expire --expire=now --all git gc --aggressive --prune=now 

    ir dabar turite vietinę git repozitoriją iš ABC subdirectory sub-d su visa istorija išsaugota.

Pastaba Daugumai programų „ git filter-branch “ turi pridėtą parametrą -- --all . Taip iš tiesų - - erdvė - - all . Tai turėtų būti paskutiniai komandos parametrai. Matley atrado, kad taupo projekto filialus ir žymes, įtrauktas į naują repo.

Pakeitimai: iš toliau pateiktų pastabų buvo pridėta įvairių pasiūlymų, kad, pvz., Būtų užtikrinta, jog saugykla iš tikrųjų yra sutrumpinta (tai ne visada buvo anksčiau).

1165
11 дек. Atsakymą pateikė Paulius 11 d. 2008-12-11 18:40 '08 18:40 pm 2008-12-11 18:40

Lengvas būdas ir prekyba;

Pasirodo, kad tai yra tokia bendra ir naudinga praktika, kad gitų viršininkai jį padarė labai paprasta, tačiau turėtumėte turėti naujesnę versiją (> = 2012 11 07). Žr. Priedą, kaip įdiegti naujausią „git“ versiją. Be to, žemiau pateiktas pavyzdys .

  • Paruoškite seną repo

     pushd <big-repo> git subtree split -P <name-of-folder> -b <name-of-new-branch> popd 

    Pastaba <name-of-folder> neturi būti pirmaujančių ar galinių simbolių. Pvz., Aplankas, pavadintas subproject turi būti perkeltas kaip subproject , NOT ./subproject/

    Pastaba Windows vartotojams: kai aplanko gylis yra> 1, <name-of-folder> turi būti * nix stiliaus separatorius (/). Pvz., Aplankas, pavadintas path1\path2\subproject turi būti perduotas kaip path1/path2/subproject

  • Sukurkite naują repo

     mkdir <new-repo> pushd <new-repo> git init git pull </path/to/big-repo> <name-of-new-branch> 
  • Prijunkite naują repo su „Github“ arba bet kur

     git remote add origin <git@github.com:my-user/new-repo.git> git push origin -u master 
  • Valymas, jei reikia

     popd # get out of <new-repo> pushd <big-repo> git rm -rf <name-of-folder> 

    Pastaba Tai palieka visas istorines nuorodas saugykloje. Toliau pateikiamas priedas , jei iš tikrųjų esate susirūpinęs, kad sukūrėte slaptažodį, arba turite sumažinti .git aplanko failo dydį.

...

„Walkthrough“

Tai yra tie patys veiksmai kaip pirmiau , bet po mano tikslių veiksmų mano saugykloje, o ne naudojant <meta-named-things> .

Čia yra projektas, kurį įgyvendinu „JavaScript“ naršyklės moduliuose mazge:

 tree ~/Code/node-browser-compat node-browser-compat ├── ArrayBuffer ├── Audio ├── Blob ├── FormData ├── atob ├── btoa ├── location └── navigator 

Noriu pasidalinti vienu aplanku, btoa , atskiroje git saugykloje

 pushd ~/Code/node-browser-compat/ git subtree split -P btoa -b btoa-only popd 

Dabar turiu naują btoa-only filialą, kuris atlieka tik operacijas, skirtas btoa , ir noriu sukurti naują saugyklą.

 mkdir ~/Code/btoa/ pushd ~/Code/btoa/ git init git pull ~/Code/node-browser-compat btoa-only 

Be to, sukuriu naują repo „Github“ arba „bitbucket“ ar kažką kito, ir pridėkite ją prie origin (btw, „kilmė“ yra tik sutartis, o ne dalis komandos - galite jį vadinti „nuotoliniu serveriu“, arba kaip norite )

 git remote add origin git@github.com:node-browser-compat/btoa.git git push origin -u master 

Laiminga diena!

Pastaba . Jei sukūrėte repo su README.md , .gitignore ir LICENSE , pirmiausia turite ištraukti:

 git pull origin -u master git push origin -u master 

Galiausiai, noriu pašalinti aplanką iš didesnio repo.

 git rm -rf btoa 

...

Taikymas

Naujausias git OS X

Jei norite gauti naujausią „git“ versiją:

 brew install git 
border=0

Jei norite gauti OS X:

http://brew.sh

Paskutinis „Ubuntu“

 sudo apt-get update sudo apt-get install git git --version 

Jei tai neveikia (turite labai seną ubuntu versiją), pabandykite

 sudo add-apt-repository ppa:git-core/ppa sudo apt-get update sudo apt-get install git 

Jei jis vis dar neveikia, pabandykite

 sudo chmod +x /usr/share/doc/git/contrib/subtree/git-subtree.sh sudo ln -s \ /usr/share/doc/git/contrib/subtree/git-subtree.sh \ /usr/lib/git-core/git-subtree 

Ačiū rui.araujo už komentarus.

aiški istorija

Pagal nutylėjimą failų ištrynimas iš „git“ iš tikrųjų jų nepašalina iš „git“, jis tiesiog pataiso, kad jie nebėra. Jei norite ištrinti istorines nuorodas (t. Y. Turite slaptažodį), turite tai padaryti:

 git filter-branch --prune-empty --tree-filter 'rm -rf <name-of-folder>' HEAD 

Po to galite patikrinti, ar failas ar aplankas visai nerodomas git istorijoje.

 git log -- <name-of-folder> # should show nothing 

Tačiau „github“ ir pan. Negalite „spustelėti“ . Jei bandysite, gausite pranešimą apie klaidą, ir jums reikės git pull kad galėtumėte git pull - ir tada grįžti į viską, kas yra jūsų istorijoje.

Taigi, jei norite ištrinti istoriją iš „kilmės“, ty ištrinti jį iš „github“, „bitbucket“ ir tt, turėsite pašalinti repo ir iš naujo pateikti trumpesnę repo kopiją. Bet palaukite - yra daugiau ! - Jei tikrai nerimaujate, kad atsikratysite slaptažodžio ar kažką panašaus, reikia nukopijuoti atsarginę kopiją (žr. Žemiau).

.git mažiau

Pirmiau pateikta ištrynimo istorijos komanda vis dar paliekama atsarginių failų krūva, nes git yra pernelyg natūra, kad padėtų jums nepažeisti jūsų repo. Galų gale, jie ištrino prarastus failus keletą dienų ir mėnesių, tačiau jie palieka juos tam tikrą laiką, jei suprasite, kad netyčia ištrynėte tai, ko nenorėjote.

Taigi, jei tikrai norite išimti krepšį, kad sumažintumėte repo klono dydį , turite tai padaryti tikrai keistai:

 rm -rf .git/refs/original/  \ git reflog expire --all  \ git gc --aggressive --prune=now git reflog expire --all --expire-unreachable=0 git repack -A -d git prune 

Tačiau, jei nežinote, ko jums reikia, rekomenduojame nesiimti šių veiksmų - tik tuo atveju, jei iškirsite neteisingą pakatalogį? Atsarginės rinkmenos neturėtų būti klonuojamos paspaudus repo, jie bus tiesiog vietinėje kopijoje.

Kreditas

1165
25 июля '13 в 20:10 2013-07-25 20:10 atsakymą pateikė „ CoolAJ86“ liepos 25 d. 13 d. 20:10 2013-07-25 20:10

Pauliaus atsakymas sukuria naują saugyklą, kurioje yra / ABC, bet neištrina / ABC iš / XYZ. Ši komanda pašalins / abc iš vidaus / xyz:

 git filter-branch --tree-filter "rm -rf ABC" --prune-empty HEAD 

Žinoma, pirmiausia išbandykite jį „klone - ne-hardlinks“ saugykloje ir vykdykite jį naudodami Pauliaus išvardytas reset, gc ir prune komandas.

131
05 июня '09 в 16:15 2009-06-05 16:15 atsakymas pateikiamas p. Birželio 05'09, 16:15 2009-06-05 16:15

Manau, kad norint tinkamai pašalinti seną istoriją iš naujos saugyklos, po filter-branch turite atlikti šiek tiek daugiau darbo.

  • Padarykite kloną ir filtruokite:

     git clone --no-hardlinks foo bar; cd bar git filter-branch --subdirectory-filter subdir/you/want 
  • Pašalinkite visas nuorodas į seną istoriją. „kilmė“ sekė jūsų kloną, o „originalas“ - tai, kur filtro filialas saugo seną medžiagą:

     git remote rm origin git update-ref -d refs/original/refs/heads/master git reflog expire --expire=now --all 
  • Net ir dabar, jūsų istorija gali būti įstrigo paketiniame faile, kurį fsck nepaliesti. Nuplėškite jį į skaldas, sukurkite naują paketinį failą ir ištrinkite nepanaudotus objektus:

     git repack -ad 

Tai paaiškinama filtro šakos vadove.

94
20 окт. Josh Lee atsakymas spalio 20 d 2009-10-20 00:10 '09 0:10 2009-10-20 00:10

Redaguoti: „Bash“ scenarijus.

Čia pateikti atsakymai iš dalies buvo susiję su manimi; Daugelis didelių failų lieka talpykloje. Kas pagaliau dirbo (po valandos per # git freenode):

 git clone --no-hardlinks file:///SOURCE /tmp/blubb cd blubb git filter-branch --subdirectory-filter ./PATH_TO_EXTRACT --prune-empty --tag-name-filter cat -- --all git clone file:///tmp/blubb/ /tmp/blooh cd /tmp/blooh git reflog expire --expire=now --all git repack -ad git gc --prune=now 

Ankstesnėse versijose saugyklos dydis buvo apie 100 MB. Tai sumažino iki 1,7 MB. Gal tai padeda kam nors :)


Šis bash scenarijus automatizuoja užduotį:

 !/bin/bash if (( $# < 3 )) then echo "Usage: $0 </path/to/repo/> <directory/to/extract/> <newName>" echo echo "Example: $0 /Projects/42.git first/answer/ firstAnswer" exit 1 fi clone=/tmp/${3}Clone newN=/tmp/${3} git clone --no-hardlinks file://$1 ${clone} cd ${clone} git filter-branch --subdirectory-filter $2 --prune-empty --tag-name-filter cat -- --all git clone file://${clone} ${newN} cd ${newN} git reflog expire --expire=now --all git repack -ad git gc --prune=now 
39
09 июня '11 в 18:41 2011-06-09 18:41 atsakymą pateikė Simonas A. Eugsteris birželio 09 '11, 18:41 2011-06-09 18:41

Tai nėra taip sunku, galite tiesiog naudoti savo repo klono komandą „ Git Filter-branch“, kad atsisakytumėte nereikalingų katalogų, o tada spustelėkite naują nuotolinį valdiklį.

 git filter-branch --prune-empty --subdirectory-filter <YOUR_SUBDIR_TO_KEEP> master git push <MY_NEW_REMOTE_URL> -f . 
22
20 авг. atsakymas, kurį davė jeremyjjbrown 20 rug . 2014-08-20 17:11 '14, 17:11 2014-08-20 17:11

Atnaujinti . „Git“ subtree modulis buvo toks naudingas, kad git komanda ištraukė ją į branduolį ir padarė jį git subtree . Žiūrėkite čia: Atskirkite (perkelkite) antrinį katalogą į atskirą git saugyklą

Git-subtree gali būti naudinga

http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt (pasenęs)

http://psionides.jogger.pl/2010/02/04/sharing-code-between-projects-with-git-subtree/

19
22 марта '10 в 23:55 2010-03-22 23:55 atsakymas pateikiamas DW kovo 22 d. 10 val. 23:55 2010-03-22 23:55

Štai nedidelis „ CoolAJ86 “ „Lengvas būdas ir prekyba“ pakeitimas. atsakyti, kad sub1 kelis poaplankius (leiskite sub1 ir sub2 ) į naują git saugyklą.

Lengvas būdas ir prekyba; (keli aplankai)

  • Paruoškite seną repo

     pushd <big-repo> git filter-branch --tree-filter "mkdir <name-of-folder>; mv <sub1> <sub2> <name-of-folder>/" HEAD git subtree split -P <name-of-folder> -b <name-of-new-branch> popd 

    Pastaba <name-of-folder> neturi būti pirmaujančių ar galinių simbolių. Pvz., Aplankas, pavadintas subproject turi būti perkeltas kaip subproject , NOT ./subproject/

    Pastaba Windows vartotojams: kai aplanko gylis yra> 1, <name-of-folder> turi būti * nix stiliaus separatorius (/). Pvz., Aplankas, pavadintas path1\path2\subproject turi būti perduotas kaip path1/path2/subproject . Taip pat nenaudokite komandos mv , bet move .

    Galutinė pastaba: unikalus ir didelis skirtumas nuo pagrindinio atsakymo yra antroji scenarijaus „ git filter-branch... “ eilutė.

  • Sukurkite naują repo

     mkdir <new-repo> pushd <new-repo> git init git pull </path/to/big-repo> <name-of-new-branch> 
  • Prijunkite naują repo su „Github“ arba bet kur

     git remote add origin <git@github.com:my-user/new-repo.git> git push origin -u master 
  • Valymas, jei reikia

     popd # get out of <new-repo> pushd <big-repo> git rm -rf <name-of-folder> 

    Pastaba Tai palieka visas istorines nuorodas saugykloje. Jei esate tikrai susirūpinę, kad padarėte slaptažodį arba turite sumažinti .git aplanko failo dydį, .git . .git .

14
06 авг. Atsakymą pateikė Anthony O. 2015-08-06 18:26 '15 , 18:26 2015-08-06 18:26

Pirminis klausimas nori, kad XYZ / ABC / (* failai) taptų ABC / ABC / (* failais). Atlikus mano kodo atsakymą, pastebėjau, kad jis iš tikrųjų keičia XYZ / ABC / (* failus) į ABC / (* failus). Filtrų šakos žmogus puslapis netgi sako

Rezultate bus šis katalogas (ir tik tas) kaip jo projekto šaknis.

Kitaip tariant, viename lygyje jis pakelia aukščiausio lygio aplanką. Tai yra svarbus skirtumas, nes, pavyzdžiui, mano istorijoje pervadinau aukščiausio lygio aplanką. Paspaudus aplankus viename lygyje, git praranda tęstinumą įsipareigojime, kur jį pervadinau.

2019

11
atsakymą pateikė MM. 17 Bal 2012-04-17 08:12 '12 at 8:12 am 2012-04-17 08:12

Norėdami pridėti Pauliaus atsakymą , pastebėjau, kad galiausiai atkursiu erdvę, turiu nuspausti HEAD į švarią saugyklą ir supjaustyti .git / objektų / pakuotės dydį.

tai yra.

 $ mkdir ... ABC.git $ cd ... ABC.git $ git init --bare

Po gc slyvų taip pat veikia:

 $ git stumti ... ABC.git HEAD

Tada galite padaryti

 $ git klonas ... ABC.git

ir ABC / .git dydis mažėja

Iš tikrųjų kai kurie laiko žingsniai (pvz., Git gc) nereikalingi, jei norite ištrinti saugyklą, ty:

 $ git klonas --no-hardlinks / XYZ / ABC $ git filtro šakos - abonemento filtras ABC HEAD $ git reset --hard $ git stumti ... ABC.git HEAD
7
25 июля '09 в 13:01 2009-07-25 13:01 Atsakymą pateikė byla Larsen, liepos 25 d., 09:01, 2009-07-25 13:01

Teisingas būdas yra dabar:

git filter-branch --prune-empty --subdirectory-filter FOLDER_NAME [first_branch] [another_branch]

Dabar „GitHub“ netgi turi mažą straipsnį apie tokius atvejus.

Tačiau nepamirškite, kad iš pradžių klonuotų šaltinio repo, kad atskirtumėte katalogą (nes jis ištrins visus failus ir kitus katalogus, ir jums gali tekti dirbti su jais). Eik

Taigi, jūsų algoritmas turėtų būti:

  • klonuoti nuotolinį repo į kitą katalogą
  • naudojant „ git filter-branch palikite tik tam tikrą pakatalogį esančius failus, spustelėkite naują nuotolinį valdiklį
  • sukurti įsipareigojimą pašalinti šį katalogą iš šaltinio nuotolinio repo
6
12 нояб. Atsakymą pateikė Olexandr Shapovalov lapkričio 12 d 2014-11-12 16:22 '14, 16:22 2014-11-12 16:22

Atrodo, kad dauguma (visi?) Atsakymai čia remiasi tam tikra git filter-branch --subdirectory-filter forma - „ git filter-branch --subdirectory-filter ir jo ilk. Tai gali veikti dažniausiai, tačiau kai kuriais atvejais, pavyzdžiui, pervadinus aplanką, pvz .:

  ABC/ /move_this_dir # did some work here, then renamed it to ABC/ /move_this_dir_renamed 

Jei sukuriate įprastą „git“ filtravimo stilių, kad išgautumėte „move_me_renamed“, prarasite failo, kuris atsirado iš nugaros, kai jis iš pradžių buvo perkeltas_this_dir ( ref ), istoriją.

Taigi, atrodo, kad vienintelis būdas iš tikrųjų išsaugoti pokyčių istoriją (jei jūsų atvejis yra panašus) iš esmės yra kopijuoti saugyklą (sukurti naują repo, nustatyti jį kaip pradžią), tada nukirpti visa kita ir pervardyti antrinį katalogą į pagrindinį elementą taip:

  • lokaliai lokalizuoti projektą su keliais moduliais
  • Filialai - patikrinkite: git branch -a
  • Patikrinkite kiekvieną skyrių, kuris bus įtrauktas į skaidinį, norėdami gauti vietinę kopiją jūsų darbo vietoje: „ git checkout --track origin/branchABC
  • Padarykite kopiją naujame kataloge: cp -r oldmultimod simple
  • Eikite į naują projekto kopiją: cd simple
  • Atsikratykite kitų modulių, kurių nereikia šiame projekte:
  • git rm otherModule1 other2 other3
  • Dabar lieka tik tikslinio modulio poskyris
  • Atsikratykite modulio katalogo, kad modulio šaknis taptų nauja projekto šaknimi.
  • git mv moduleSubdir1/* .
  • Ištrinkite subdir: rmdir moduleSubdir1 : rmdir moduleSubdir1
  • Patikrinkite pakeitimus bet kuriuo metu: git status
  • Sukurkite naują git saugyklą ir nukopijuokite jo URL, kad nukreiptumėte šį projektą:
  • git remote set-url origin http://mygithost:8080/git/our-splitted-module-repo
  • Įsitikinkite, kad tai gerai: git remote -v
  • Spustelėkite pakeitimus nuotolinio repo: git push
  • Eikite į nuotolinį repo ir patikrinkite jį.
  • Pakartokite jį bet kuriai kitai git checkout branch2 : git checkout branch2

Tai atitinka „ github doc“ „Apatinio aplanko suskirstymą į naują saugyklą“ žingsnius 6-11, kad modulis būtų perkeliamas į naują repo.

Tai neleis jums išsaugoti jokios vietos .git aplanke, bet išsaugos visą šių failų pakeitimo istoriją net ir pervadinus. Ir tai gali būti ne verta, jei nėra „didelės“ istorijos, prarado ir pan. Bet bent jau esate garantuotas, kad neprarandate senesnių įsipareigojimų!

5
19 сент. atsakymas pateikiamas rogerdpack 19 sep . 2016-09-19 21:46 '16 at 21:46 2016-09-19 21:46

Dėl to, ką verta, čia galite naudoti „GitHub“ „Windows“ įrenginyje. Tarkime, kad jūs turite klonuotą repo, kai apsistojate C:\dir1 Rodyklės struktūra atrodo taip: C:\dir1\dir2\dir3 dir3 katalogas yra tas, kurį noriu būti nauju individualiu repo.

Github:

  • Sukurti naują saugyklą: „ MyTeam/mynewrepo

„Bash Request“:

  1. $ cd c:/Dir1
  2. $ git filter-branch --prune-empty --subdirectory-filter dir2/dir3 HEAD
    Grąžinimas: Ref 'refs/heads/master' was rewritten (fyi: dir2 / dir3 yra didžiosios ir mažosios raidės.)

  3. $ git remote add some_name git@github.com:MyTeam/mynewrepo.git
    git remote add origin etc neveikia, grąžina „ remote origin already exists

  4. $ git push --progress some_name master

4
07 февр. James Lawruk atsakymas 07 vasaris 2012-02-07 22:07 '12 - 10:07 pm 2012-02-07 22:07

Aš turėjau šią ypatingą problemą, bet visi standartiniai sprendimai, pagrįsti git filtro šakomis, buvo labai lėti. Jei turite mažą saugyklą, tai gali būti ne problema, tai buvo man. Parašiau kitą „libgit2“ pagrindu sukurtą „git“ filtravimo programą, kuri, kaip pirmasis žingsnis, sukuria filialus kiekvienam pagrindinio saugyklos filtravimui ir tada juos verčia išvalyti saugyklas kaip kitą žingsnį. Mano saugykloje (500 MB 100000) standartiniai filtravimo metodai su git filtrais užtruko kelias dienas. Mano programa trunka kelias minutes, kad atliktų tą patį filtravimą.

Šis nuostabus vardas yra „git_filter“ ir gyvena čia:

https://github.com/slobobaby/git_filter

apie github.

Tikiuosi, kad tai naudinga kitam.

4
10 марта '14 в 20:39 2014-03-10 20:39 atsakymas pateikiamas slobobaby kovo 10 d. 14 val. 20:39 2014-03-10 20:39

Kaip jau minėjau, turėjau naudoti atvirkštinį sprendimą (ištrinti visus įsipareigojimus, kurie neturėjo įtakos mano dir/subdir/targetdir ), o tai atrodė gana gerai, pašalindama apie 95% (neprivaloma). Tačiau yra du nedideli klausimai.

PIRMOJI , filter-branch atliko užduotį pašalinti kodą įvedančius ar keičiančius įsipareigojimus, tačiau atrodo, kad susijungimai yra Gitiverse stotyje.

Tai kosmetikos problema, su kuria galiu gyventi (sako jis ... lėtai stumia akis).

ANTRAŠTINĖ DALIS Keletas likusių įsipareigojimų yra beveik dubliuojami VISI ! Panašu, kad įgavau antrą, nereikalingą laiką, apimantį beveik visą projekto istoriją. Интересная вещь (которую вы можете видеть из рисунка ниже) состоит в том, что мои три локальные ветки не все находятся на одной временной шкале (что, конечно же, почему она существует и не просто собирается мусором).

Единственное, что я могу себе представить, это то, что одним из удаленных коммитов было, пожалуй, одно единственное объединение, которое filter-branch действительно удалило, и это создало параллельную временную шкалу, поскольку каждая теперь невнесенная цепочка взяла свою собственную копию совершает. (пожал плечами Где мой ТАРДИ?) Я уверен, что смогу исправить эту проблему, хотя мне очень хотелось бы понять, как это произошло.