Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터와 같은 여러 무료 온라인 워크스테이션 중 하나를 사용하여 OnWorks 무료 호스팅 제공업체에서 실행할 수 있는 git-fast-import 명령입니다.
프로그램:
이름
git-fast-import - 빠른 Git 데이터 가져오기를 위한 백엔드
개요
프론트엔드 | 자식 빠른 가져오기 [옵션]
기술
이 프로그램은 일반적으로 최종 사용자가 직접 실행하려는 프로그램이 아닙니다. 대부분의 최종 사용자가 원하는
특정 유형의 외국어를 구문 분석하는 기존 프런트엔드 프로그램 중 하나를 사용하려면
거기에 저장된 콘텐츠를 소스로 제공하고 자식 빠른 가져오기.
fast-import는 표준 입력에서 혼합된 명령/데이터 스트림을 읽고 하나 이상의 내용을 씁니다.
현재 저장소에 직접 packfile을 추가합니다. 표준입력으로 EOF를 받았을 때,
빠른 가져오기는 업데이트된 분기 및 태그 참조를 작성하여 현재 저장소를 완전히 업데이트합니다.
새로 가져온 데이터로.
빠른 가져오기 백엔드 자체는 빈 저장소(이미
에 의해 초기화되었습니다 자식 INIT) 또는 기존의 채워진 저장소를 점진적으로 업데이트합니다.
특정 외국 소스에서 증분 가져오기가 지원되는지 여부는 다음과 같습니다.
사용중인 프론트엔드 프로그램에서
옵션
--힘
커밋이 발생하더라도 수정된 기존 브랜치를 강제로 업데이트합니다.
손실되었습니다(새 커밋에 이전 커밋이 포함되어 있지 않기 때문).
--조용한
치명적이지 않은 모든 출력을 비활성화하고 성공하면 빠른 가져오기를 자동으로 만듭니다. 이것
옵션은 --stats로 표시되는 출력을 비활성화합니다.
--통계
fast-import가 생성한 객체, 즉 팩파일에 대한 몇 가지 기본 통계를 표시합니다.
이 실행 중에 빠른 가져오기에 저장되었으며 메모리가 사용되었습니다. 전시
이 출력은 현재 기본값이지만 --quiet를 사용하여 비활성화할 수 있습니다.
옵션 for 프런트 엔드
--cat-blob-fd=
get-mark, cat-blob 및 ls 쿼리에 대한 응답을 파일 설명자에 씁니다.
표준 출력 대신. 최종 사용자를 위한 진행 출력을 분리할 수 있습니다.
다른 출력에서.
--날짜-형식=
작성자 내에서 빠른 가져오기를 위해 프런트엔드가 제공할 날짜 유형을 지정합니다.
커미터 및 태거 명령. 자세한 내용은 아래 "날짜 형식"을 참조하세요.
형식과 해당 구문이 지원됩니다.
--완료
스트림 끝에 완료된 명령이 없으면 오류와 함께 종료됩니다. 이 옵션
프런트엔드가 종료되기 전에 종료되는 오류를 감지하는 데 유용할 수 있습니다.
스트림을 쓰기 시작했습니다.
쇼룸위치 of 점수 파일
--수출 마크=
내부 마크 테이블을 다음에 덤프합니다. 완료되면. 마크는 한 줄에 하나씩 기록됩니다.
:markid SHA-1로. 프런트엔드는 이 파일을 사용하여 가져오기가 완료된 후 가져오기를 검증할 수 있습니다.
완료하거나 증분 실행을 통해 마크 테이블을 저장합니다. 처럼 오직
체크포인트(또는 완료) 시 열리고 잘려도 동일한 경로를 안전하게 사용할 수 있습니다.
--import-marks에 제공됩니다.
--수입 마크=
입력을 처리하기 전에 다음에 지정된 마크를 로드합니다. . 입력 파일은 반드시
존재하고 읽을 수 있어야 하며 --export-marks에 의해 생성된 것과 동일한 형식을 사용해야 합니다.
둘 이상의 마크 세트를 가져오기 위해 여러 옵션이 제공될 수 있습니다. 마크가 있는 경우
다른 값으로 정의되면 마지막 파일이 우선합니다.
--import-marks-if-exists=
--import-marks와 비슷하지만 오류가 발생하는 대신 자동으로 파일을 건너뜁니다.
존재하지 않습니다.
--[no-]상대 표시
--relative-marks를 지정한 후 --import-marks=로 지정된 경로를 지정하고
--export-marks=는 현재 저장소의 내부 디렉터리에 상대적입니다. ~ 안에
git-fast-import 이는 경로가 .git/info/fast-import에 상대적임을 의미합니다.
예배 규칙서. 그러나 다른 수입업자는 다른 위치를 사용할 수 있습니다.
상대 표시와 비상대 표시는 --(no-)-relative-mark를 엮어 결합할 수 있습니다.
--(import|export)-marks= 옵션을 사용합니다.
퍼포먼스 와 압축 동조
--활성-분기=
한 번에 활성 상태를 유지할 수 있는 최대 분기 수입니다. 아래의 "메모리 활용도"를 참조하세요.
자세한 내용은. 기본값은 5입니다.
--큰 파일-임계값=
빠른 가져오기가 델타 생성을 시도하는 blob의 최대 크기입니다.
바이트 단위. 기본값은 512m(512MiB)입니다. 일부 수입업자는 이 금액을 낮추기를 원할 수도 있습니다.
메모리가 제한된 시스템.
--깊이=
블롭 및 트리 델타화를 위한 최대 델타 깊이입니다. 기본값은 10입니다.
--내보내기-팩-가장자리=
packfile을 생성한 후 데이터 라인을 인쇄합니다. 파일 이름 나열
packfile과 해당 packfile에 기록된 각 브랜치의 마지막 커밋입니다. 이것
전체 객체 세트가 다음을 초과하는 프로젝트를 가져온 후에 정보가 유용할 수 있습니다.
4GiB 팩 파일 제한(이러한 커밋은 호출 중에 에지 포인트로 사용될 수 있음) 자식
팩 개체.
--최대-팩-크기=
각 출력 팩 파일의 최대 크기입니다. 기본값은 무제한입니다.
성능
빠른 가져오기 설계를 통해 최소한의 메모리로 대규모 프로젝트를 가져올 수 있습니다.
사용 및 처리 시간. 프런트엔드가 빠른 가져오기 및
지속적인 데이터 흐름을 제공하고 10년 이상의 역사를 보유한 프로젝트의 가져오기 시간
100,000개 이상의 개별 커밋을 포함하는 경우 일반적으로 1~2시간 만에 완료됩니다.
아주 적당한 수준(~$2,000 USD)의 하드웨어입니다.
대부분의 병목 현상은 외부 소스 데이터 액세스에 있는 것으로 보입니다(소스는
충분히 빠른 속도로 개정판 추출) 또는 디스크 IO(빠른 가져오기 쓰기는 디스크가 수행하는 속도만큼 빠르게 작성)
데이터를 가져옵니다). 원본 데이터가 다른 드라이브에 저장되어 있으면 가져오기가 더 빠르게 실행됩니다.
대상 Git 저장소보다 (IO 경합이 적기 때문에)
개발 COST
빠른 가져오기를 위한 일반적인 프런트엔드는 약 200줄에 달하는 경향이 있습니다.
펄/파이썬/루비 코드. 대부분의 개발자는 단 몇 시간 만에 작동하는 임포터를 만들 수 있었습니다.
빠른 가져오기에 대한 첫 번째 노출임에도 불구하고 몇 시간이 걸리고 때로는
심지어 Git에도요. 대부분의 변환 도구가 일회용이라는 점을 고려하면 이는 이상적인 상황입니다.
(한 번 사용하고 뒤돌아보지 마십시오).
평행 운영
처럼 자식 푸시 or 자식 술책, fast-import로 처리되는 가져오기는 함께 실행해도 안전합니다.
병렬 git repack -a -d 또는 git gc 호출 또는 기타 Git 작업(포함) 자식
치다, 느슨한 객체는 빠른 가져오기에서 사용되지 않기 때문입니다).
fast-import는 적극적으로 가져오는 브랜치나 태그 참조를 잠그지 않습니다. 후
import는 참조 업데이트 단계에서 fast-import가 각 기존 분기 참조를 테스트하여 확인합니다.
업데이트는 빠른 업데이트가 됩니다(ref에 저장된 커밋은
작성될 커밋의 새로운 기록). 업데이트가 빠른 업데이트가 아닌 경우,
fast-import는 해당 참조 업데이트를 건너뛰고 대신 경고 메시지를 인쇄합니다. 빠른 가져오기
항상 모든 분기 참조를 업데이트하려고 시도하며 첫 번째 실패 시 중지되지 않습니다.
--force를 사용하여 분기 업데이트를 강제할 수 있지만 다음에서만 사용하는 것이 좋습니다.
그렇지 않으면 조용한 저장소. 처음 가져오기에는 --force를 사용할 필요가 없습니다.
빈 저장소.
기술 토론
fast-import는 메모리에 있는 일련의 분기를 추적합니다. 모든 브랜치는 다음에서 생성되거나 수정될 수 있습니다.
입력 스트림에서 커밋 명령을 전송하여 가져오기 프로세스 중 어느 시점에서든 가능합니다. 이것
디자인을 통해 프런트엔드 프로그램이 무제한의 분기를 처리할 수 있습니다.
동시에 소스 데이터에서 사용 가능한 순서대로 커밋을 생성합니다.
또한 프런트엔드 프로그램을 상당히 단순화합니다.
fast-import는 현재 작업 디렉터리나 그 안에 있는 파일을 사용하거나 변경하지 않습니다.
(그러나 GIT_DIR에서 참조하는 대로 현재 Git 저장소를 업데이트합니다.)
가져오기 프런트엔드는 추출과 같은 자체 목적으로 작업 디렉토리를 사용할 수 있습니다.
외국 소스의 파일 개정판. 작업 디렉토리에 대한 이러한 무지 또한
비용이 많이 드는 파일을 수행할 필요가 없으므로 빠른 가져오기를 매우 빠르게 실행할 수 있습니다.
지점 간 전환 시 업데이트 작업.
입력 FORMAT
Git이 해석하지 않는 원시 파일 데이터를 제외하고 빠른 가져오기 입력
형식은 텍스트(ASCII) 기반입니다. 이 텍스트 기반 형식은 개발 및 디버깅을 단순화합니다.
특히 Perl, Python 또는 Ruby와 같은 고급 언어의 경우 프론트엔드 프로그램
사용 중입니다.
fast-import는 입력에 대해 매우 엄격합니다. 아래에서 SP라고 하면 다음을 의미합니다. 정확하게 한
공간. 마찬가지로 LF는 하나의(단 하나의) 라인피드를 의미하고 HT는 하나의(단 하나의) 수평 라인피드를 의미합니다.
탭. 추가 공백 문자를 제공하면 다음과 같은 예상치 못한 결과가 발생합니다.
이름 앞이나 뒤에 공백이 있는 분기 이름이나 파일 이름, 또는 초기
예상치 못한 입력이 발생하면 빠른 가져오기가 종료됩니다.
흐름 코멘트
프런트엔드 디버깅을 돕기 위해 fast-import는 #(ASCII)로 시작하는 모든 줄을 무시합니다.
파운드/해시) LF로 끝나는 줄까지 포함합니다. 주석 줄에는 다음이 포함될 수 있습니다.
LF를 포함하지 않으므로 LF를 포함하는 데 사용될 수 있는 바이트 시퀀스
프런트엔드에 특정하고 다음과 같은 경우에 유용할 수 있는 자세한 디버깅 정보
빠르게 가져오는 데이터 스트림을 검사합니다.
날짜 형식
다음 날짜 형식이 지원됩니다. 프런트엔드는 사용할 형식을 선택해야 합니다.
--date-format=에 형식 이름을 전달하여 이 가져오기를 수행합니다. 명령줄 옵션.
살갗이 벗어 진
이는 Git 기본 형식이며 SP . 또한 빠른 수입품이기도 합니다.
--date-format이 지정되지 않은 경우 기본 형식입니다.
이벤트 시간은 다음과 같이 지정됩니다. UNIX 이후의 초 수
epoch(1년 1970월 XNUMX일 자정, UTC)이며 ASCII 십진 정수로 작성됩니다.
로컬 오프셋은 다음과 같이 지정됩니다. UTC로부터의 양수 또는 음수 오프셋입니다.
예를 들어 EST(UTC보다 5시간 늦음)는 다음과 같이 표현됩니다. "-0500" 기준
UTC는 "+0000"입니다. 로컬 오프셋은 영향을 미치지 않습니다. ; 그것은 단지
형식 지정 루틴에서 타임스탬프를 표시하는 데 도움이 되는 조언입니다.
소스 자료에서 로컬 오프셋을 사용할 수 없는 경우 "+0000"을 사용하거나 가장
공통 로컬 오프셋. 예를 들어 많은 조직에는 다음과 같은 CVS 저장소가 있습니다.
동일한 위치 및 시간대에 있는 사용자만 액세스한 적이 있습니다.
이 경우 UTC로부터의 합리적인 오프셋이 가정될 수 있습니다.
rfc2822 형식과 달리 이 형식은 매우 엄격합니다. 형식의 모든 변형
빠른 가져오기가 값을 거부하게 됩니다.
RFC2822
이는 RFC 2822에 설명된 표준 이메일 형식입니다.
예제 값은 "Tue Feb 6 11:22:18 2007 -0500"입니다. Git 파서는 정확하지만
조금 관대 한 편입니다. 에서 사용하는 것과 동일한 파서입니다. 자식 am 패치를 적용할 때
이메일로 받았습니다.
일부 잘못된 문자열은 유효한 날짜로 받아들여질 수 있습니다. 이러한 경우 Git은
잘못된 문자열에서 올바른 날짜를 얻을 수 있습니다. 또한 있다
Git이 잘못 구문 분석하지만 유효한 것으로 간주하는 일부 유형의 잘못된 문자열입니다.
심각하게 잘못된 문자열은 거부됩니다.
위의 원시 형식과 달리 RFC에 포함된 시간대/UTC 오프셋 정보는
2822 날짜 문자열은 저장하기 전에 날짜 값을 UTC로 조정하는 데 사용됩니다. 그러므로
이 정보는 최대한 정확해야 합니다.
소스 자료가 RFC 2822 스타일 날짜를 사용하는 경우 프런트엔드는 빠른 가져오기를 허용해야 합니다.
Git으로 구문 분석 및 변환을 처리합니다(자체적으로 시도하는 대신).
파서는 실제 환경에서 잘 테스트되었습니다.
소스 자료가 이미 UNIX-epoch를 사용하는 경우 프런트엔드는 원시 형식을 선호해야 합니다.
형식을 사용하여 해당 형식으로 날짜를 제공할 수 있습니다. 또는 해당 형식을 쉽게 사용할 수 있습니다.
구문 분석에 모호함이 없기 때문에 변환 가능합니다.
지금
항상 현재 시간과 시간대를 사용하십시오. 이제 리터럴은 항상 제공되어야 합니다.
.
이것은 장난감 형식입니다. 이 시스템의 현재 시간과 시간대가 항상 복사됩니다.
빠른 가져오기로 생성될 때 ID 문자열에 추가됩니다. 없다
다른 시간이나 시간대를 지정하는 방법.
이 특정 형식은 구현이 짧고 다음 작업에 유용할 수 있으므로 제공됩니다.
작업을 사용할 필요 없이 지금 바로 새로운 커밋을 생성하려는 프로세스
디렉토리 또는 자식 업데이트 인덱스.
별도의 작성자 및 커미터 명령이 커밋에 사용되는 경우 타임스탬프가 표시되지 않을 수 있습니다.
시스템 시계는 두 번(각 명령에 대해 한 번씩) 폴링되므로 일치합니다. 유일한 방법
작성자와 커미터 신원 정보 모두 동일한 타임스탬프를 갖도록 보장합니다.
작성자를 생략하거나(따라서 커미터에서 복사) 다른 날짜 형식을 사용하는 것입니다.
지금.
명령
fast-import는 현재 저장소를 업데이트하고
현재 수입 과정. 각 명령에 대한 자세한 설명(예제 포함)은 다음과 같습니다.
나중에.
범하다
새로운 커밋을 생성하여 새 브랜치를 생성하거나 기존 브랜치를 업데이트합니다.
새로 생성된 커밋을 가리키도록 분기를 업데이트합니다.
태그
기존 커밋 또는 분기에서 주석이 달린 태그 개체를 만듭니다. 경량 태그
녹음에 권장되지 않으므로 이 명령에서는 지원되지 않습니다.
의미 있는 시점.
재설정
기존 분기(또는 새 분기)를 특정 개정으로 재설정합니다. 이 명령은 반드시
커밋을 하지 않고 브랜치를 특정 개정판으로 변경하는 데 사용됩니다.
윤곽이 흐릿한 것
나중에 커밋 명령에 사용할 수 있도록 원시 파일 데이터를 Blob으로 변환합니다. 이 명령은
선택 사항이며 가져오기를 수행하는 데 필요하지 않습니다.
체크 포인트
빠른 가져오기를 통해 현재 팩 파일을 닫고 고유한 SHA-1 체크섬을 생성합니다.
색인을 생성하고 새 팩파일을 시작합니다. 이 명령은 선택 사항이므로 필요하지 않습니다.
가져오기를 수행합니다.
진행
fast-import가 전체 행을 자체 표준 출력에 반영하도록 합니다. 이 명령은
선택 사항이며 가져오기를 수행하는 데 필요하지 않습니다.
한
스트림의 끝을 표시합니다. 완료 기능이 실행되지 않는 한 이 명령은 선택 사항입니다.
--done 명령줄 옵션 또는 기능 완료 명령을 사용하여 요청했습니다.
마크 획득
fast-import가 마크에 해당하는 SHA-1을 파일 설명자에 인쇄하도록 합니다.
--cat-blob-fd로 설정하거나 지정하지 않은 경우 stdout으로 설정합니다.
고양이 덩어리
빠른 가져오기로 인해 blob이 인쇄됩니다. 고양이 파일 --일괄 파일 설명자에 대한 형식
지정되지 않은 경우 --cat-blob-fd 또는 stdout으로 설정합니다.
ls
fast-import가 디렉토리 항목을 설명하는 행을 인쇄하도록 합니다. ls-트리 형식
지정되지 않은 경우 --cat-blob-fd 또는 stdout으로 설정된 파일 설명자.
기능
지정된 기능을 활성화합니다. 이를 위해서는 fast-import가 지정된 항목을 지원해야 합니다.
기능이 없으면 중단됩니다.
선택권
스트림 의미를 다음으로 변경하지 않는 옵션 아래에 나열된 옵션을 지정하십시오.
프론트엔드의 요구에 맞게. 이 명령은 선택 사항이며 작업을 수행하는 데 필요하지 않습니다.
수입.
범하다
새로운 커밋으로 브랜치를 생성하거나 업데이트하여 프로젝트에 하나의 논리적 변경 사항을 기록합니다.
SP '커밋' LF
표시?
('저자'(SP )? SP LT GTSP LF)?
'커미터'(SP )? SP LT GTSP LF
데이터
('에서' SP LF)?
('병합' SP LF)?
(파일 수정 | 파일 삭제 | 파일 복사 | 파일 이름 바꾸기 | 파일 삭제 | 메모수정)*
LF?
어디 커밋을 수행할 브랜치의 이름입니다. 일반적으로 지점 이름은 다음과 같습니다.
Git에서는 refs/heads/ 접두사가 붙어 있으므로 CVS 분기 기호 RELENG-1_0을 가져오면 다음이 사용됩니다.
값에 대한 refs/heads/RELENG-1_0 . 의 가치 유효한 참조 이름이어야 합니다.
Git에서. Git 참조 이름에서는 LF가 유효하지 않으므로 인용 또는 이스케이프 구문이 지원되지 않습니다.
여기를 클릭해 문의해주세요.
선택적으로 표시 명령이 나타나서 참조를 저장하기 위해 빠른 가져오기를 요청합니다.
나중에 프런트엔드에서 사용하기 위해 새로 생성된 커밋(형식은 아래 참조) 그것은 매우
프런트엔드에서는 자신이 생성한 모든 커밋을 표시하여 향후 분기를 허용하는 것이 일반적입니다.
가져온 커밋에서 생성됩니다.
커미터 다음의 데이터 명령은 커밋 메시지를 제공해야 합니다(데이터는 아래 참조).
명령 구문). 빈 커밋 메시지를 가져오려면 길이가 0인 데이터를 사용하세요. 커밋 메시지
자유 형식이며 Git에서 해석되지 않습니다. 현재는 UTF-8로 인코딩되어야 합니다.
fast-import는 다른 인코딩 지정을 허용하지 않습니다.
XNUMX개 이상의 filemodify, filedelete, filecopy, filerename, filedeleteall 및 notemodify
브랜치를 생성하기 전에 브랜치의 내용을 업데이트하는 명령이 포함될 수 있습니다.
저지르다. 이러한 명령은 순서에 관계없이 제공될 수 있습니다. 그러나 다음을 수행하는 것이 좋습니다.
fileleteall 명령은 모든 filemodify, filecopy, filerename 및 notemodify 명령 앞에 옵니다.
동일한 커밋에서 filedeleteall이 브랜치를 깨끗하게 지웁니다(아래 참조).
명령 뒤의 LF는 선택 사항입니다(예전에는 필수였습니다).
저자
작성자 정보가 작성자 명령과 다를 수 있는 경우 작성자 명령이 선택적으로 나타날 수 있습니다.
커미터 정보. 작성자를 생략하면 빠른 가져오기가 자동으로 수행됩니다.
커밋의 작성자 부분에 커미터 정보를 사용합니다. 자세한 내용은 아래를 참조하세요.
작성자의 필드에 대한 설명은 커미터와 동일합니다.
커미터
커미터 명령은 커밋을 수행한 사람과 수행한 시기를 나타냅니다.
여기 그 사람의 표시 이름(예: "Com M Itter")이고 ~이다
그 사람의 이메일 주소('[이메일 보호]"). LT와 GT는 문자 그대로 작음입니다.
(\x3c) 및 보다 큼(\x3e) 기호. 이메일을 구분하는 데 필요합니다.
줄에 있는 다른 필드의 주소입니다. 참고하세요 그리고 자유 형식이다
LT, GT 및 LF를 제외한 모든 바이트 시퀀스를 포함할 수 있습니다. 일반적으로 UTF-8입니다.
인코딩.
변경 시간은 다음과 같이 지정됩니다. 선택한 날짜 형식을 사용하여
--date-format=에 의해 명령줄 옵션. 세트에 대해서는 위의 "날짜 형식"을 참조하세요.
지원되는 형식 및 해당 구문.
에
from 명령은 이 브랜치를 초기화할 커밋을 지정하는 데 사용됩니다. 이것
개정판은 새 커밋의 첫 번째 조상이 됩니다. 나무가 세워진 상태
이 커밋은 from 커밋의 상태로 시작하고 다음에 의해 변경됩니다.
이 커밋의 콘텐츠 수정.
새 브랜치의 첫 번째 커밋에서 from 명령을 생략하면 빠른 가져오기가 발생합니다.
조상 없이 해당 커밋을 생성합니다. 이는 초기에만 바람직한 경향이 있습니다.
프로젝트를 커밋합니다. 프런트엔드에서 새 파일을 만들 때 처음부터 모든 파일을 생성하는 경우
브랜치에서는 빈 커밋을 시작하기 위해 from 대신 병합 명령을 사용할 수 있습니다.
나무. 일반적으로 기존 분기에서는 from 명령을 생략하는 것이 바람직합니다.
해당 브랜치의 현재 커밋은 자동으로 해당 브랜치의 첫 번째 조상으로 간주됩니다.
새로운 커밋.
Git 참조 이름 또는 SHA-1 표현식에서는 LF가 유효하지 않으므로 인용 또는 이스케이프 구문이 없습니다.
내에서 지원됩니다. .
여기 다음 중 하나입니다.
· fast-import의 내부 분기 테이블에 이미 있는 기존 분기의 이름입니다. 만약에
fast-import는 이름을 모르며 SHA-1 표현식으로 처리됩니다.
· 마크 참조, : , 어디 마크 번호입니다.
fast-import가 사용하는 이유: 마크 참조를 표시하기 위해 이 문자는
Git 브랜치 이름에 합법적입니다. 선행 : 두 항목을 쉽게 구별할 수 있도록 해줍니다.
마크 42(:42) 및 브랜치 42(42 또는 refs/heads/42) 또는 축약된 SHA-1
이는 10진법 숫자로만 구성되었습니다.
마크는 사용하기 전에 (마크를 통해) 선언되어야 합니다.
· 전체 40바이트 또는 약식 커밋 SHA-1(XNUMX진수).
· 커밋으로 확인되는 유효한 Git SHA-1 표현식. "지정"을 참조하십시오.
개정” gitrevisions(7) 자세한 내용은.
· 특수 null SHA-1(40 XNUMX개)은 분기가 제거되도록 지정합니다.
현재 분기 값에서 증분 가져오기를 다시 시작하는 특수한 경우
다음과 같이 작성되어야 합니다:
심판/헤드/브랜치^0에서
빠른 가져오기에서는 분기 시작을 허용하지 않으므로 ^0 접미사가 필요합니다.
그 자체이며 from 명령을 읽기 전에 분기가 메모리에 생성됩니다.
입력. ^0을 추가하면 빠른 가져오기가 Git을 통해 커밋을 해결하도록 강제됩니다.
내부 분기 테이블이 아닌 개정 구문 분석 라이브러리를 사용하여 로드합니다.
지점의 기존 가치.
병합
하나의 추가 상위 커밋을 포함합니다. 추가 상위 링크는 변경되지 않습니다.
이 커밋에서 트리 상태가 구축되는 방식입니다. from 명령이 생략된 경우
새 브랜치를 생성하면 첫 번째 병합 커밋이 해당 브랜치의 첫 번째 조상이 됩니다.
현재 커밋이 실행되고 브랜치는 파일 없이 시작됩니다. 무제한
커밋당 병합 명령은 fast-import에서 허용되므로 n-way를 설정합니다.
병합합니다.
여기 from에서도 허용되는 커밋 사양 표현식 중 하나입니다.
(위 참조).
파일수정
새 파일을 추가하거나 기존 파일의 내용을 변경하기 위해 커밋 명령에 포함됩니다.
파일. 이 명령에는 파일 내용을 지정하는 두 가지 방법이 있습니다.
외부 데이터 형식
파일의 데이터 콘텐츠는 이전 blob 명령에서 이미 제공되었습니다. 그만큼
프론트엔드는 연결만 하면 됩니다.
'M' SP SP SP LF
여기서는 보통 마크 참조(: ) 이전에 설정됨
blob 명령 또는 기존 Git blob 객체의 전체 40바이트 SHA-1입니다. 만약에 ~이다
040000` 그러면 기존 Git 트리의 전체 40바이트 SHA-1이어야 합니다.
--import-marks로 설정된 객체 또는 마크 참조.
인라인 데이터 형식
파일의 데이터 콘텐츠가 아직 제공되지 않았습니다. 프론트엔드가 원하는 것
이 수정 명령의 일부로 이를 제공하십시오.
'M'SP SP '인라인' SP LF
데이터
data 명령에 대한 자세한 설명은 아래를 참조하세요.
두 형식 모두 XNUMX진수로 지정된 파일 항목 유형입니다. Git 전용
다음 모드를 지원합니다.
· 100644 또는 644: 일반(실행할 수 없는) 파일입니다. 대부분의 파일은 대부분
프로젝트에서는 이 모드를 사용합니다. 의심스럽다면 이것이 바로 당신이 원하는 것입니다.
· 100755 또는 755: 정상이지만 실행 가능한 파일입니다.
· 120000: 심볼릭 링크, 파일 내용이 링크 대상이 됩니다.
· 160000: 개체의 gitlink, SHA-1이 다른 저장소의 커밋을 참조합니다.
Git 링크는 SHA 또는 커밋 표시를 통해서만 지정할 수 있습니다. 그들은 익숙하다
서브모듈을 구현합니다.
· 040000: 하위 디렉터리입니다. 하위 디렉터리는 SHA 또는
--import-marks로 설정된 트리 마크.
두 형식 모두 추가할 파일의 전체 경로입니다(아직 그렇지 않은 경우).
기존) 또는 수정됨(이미 존재하는 경우).
ㅏ 문자열은 UNIX 스타일 디렉터리 구분 기호(슬래시 /)를 사용해야 합니다.
LF 이외의 바이트를 포함하고 큰따옴표(")로 시작할 수 없습니다.
경로는 C 스타일 문자열 인용을 사용할 수 있습니다. 이는 모든 경우에 허용되며 다음과 같은 경우 필수입니다.
파일 이름은 큰따옴표로 시작하거나 LF를 포함합니다. C 스타일 인용에서는 완전한
이름은 큰따옴표로 묶어야 하며 LF, 백슬래시 또는 큰따옴표로 묶어야 합니다.
문자는 앞에 백슬래시를 붙여 이스케이프해야 합니다(예: "path/with\n, \\
그리고 \" 안에").
의 가치 정식 형식이어야 합니다. 즉, 다음과 같은 행위를 해서는 안 됩니다.
· 빈 디렉토리 구성요소를 포함합니다(예: foo//bar는 유효하지 않습니다).
· 디렉토리 구분 기호로 끝납니다(예: foo/는 유효하지 않습니다).
· 디렉토리 구분 기호로 시작합니다(예: /foo는 유효하지 않습니다).
· 특수 구성 요소를 포함합니다. 또는 ..(예: foo/./bar 및 foo/../bar는
유효하지 않은).
트리의 루트는 다음과 같이 빈 문자열로 표현될 수 있습니다. .
권장되는 사항은 다음과 같습니다. 항상 UTF-8을 사용하여 인코딩됩니다.
파일 삭제
파일을 제거하거나 전체를 반복적으로 삭제하는 커밋 명령에 포함됩니다.
지점의 디렉토리. 파일 또는 디렉터리 제거로 인해 상위 디렉터리가 만들어지는 경우
비어 있으면 상위 디렉터리도 자동으로 제거됩니다. 이는 계단식으로
비어 있지 않은 첫 번째 디렉터리나 루트에 도달할 때까지 트리를 탐색합니다.
'D' SP LF
여기 은(는) 제거할 파일 또는 하위 디렉터리의 전체 경로입니다.
나뭇가지. 자세한 설명은 위의 filemodify를 참조하세요. .
파일 복사
기존 파일이나 하위 디렉터리를 다른 위치에 반복적으로 복사합니다.
나뭇가지. 기존 파일이나 디렉터리가 있어야 합니다. 목적지가 존재하는 경우
소스에서 복사한 콘텐츠로 완전히 대체됩니다.
'C' SP SP LF
여기서 첫 번째 은 소스 위치이고 두 번째는 목적지입니다.
자세한 내용은 위의 filemodify를 참조하세요. 처럼 보일 수도 있습니다. 사용하려면
SP가 포함된 소스 경로는 따옴표로 묶어야 합니다.
파일 복사 명령은 즉시 적용됩니다. 소스 위치가 복사되면
소스 위치에 적용되는 향후 명령은 대상에 영향을 미치지 않습니다.
복사본의 대상입니다.
파일 이름 바꾸기
기존 파일이나 하위 디렉터리의 이름을 분기 내의 다른 위치로 바꿉니다.
기존 파일이나 디렉터리가 있어야 합니다. 목적지가 존재하는 경우
소스 디렉터리로 대체됩니다.
'R'SP SP LF
여기서 첫 번째 은 소스 위치이고 두 번째는 목적지입니다.
자세한 내용은 위의 filemodify를 참조하세요. 처럼 보일 수도 있습니다. 사용하려면
SP가 포함된 소스 경로는 따옴표로 묶어야 합니다.
filerename 명령은 즉시 적용됩니다. 소스 위치가 지정되면
소스 위치에 적용되는 향후 명령은 대상으로 이름이 변경됩니다.
거기에 새 파일을 만들고 이름 바꾸기 대상에 영향을 주지 않습니다.
파일 이름 바꾸기는 파일 복사 뒤에 파일 삭제가 오는 것과 동일합니다.
소스 위치. filerename을 사용하면 약간의 성능 이점이 있지만
이점이 너무 작아서 삭제/추가 쌍을 변환하려고 시도할 가치가 없습니다.
빠른 가져오기를 위해 소스 자료의 이름을 바꿉니다. 이 파일 이름 바꾸기 명령이 제공됩니다.
이미 이름 변경 정보가 있고 귀찮게 하고 싶지 않은 프런트엔드를 단순화하기 위한 것입니다.
그것을 파일 복사본으로 분해한 다음 파일 삭제를 수행합니다.
파일삭제전체
모든 파일(및 모든 디렉터리)을 제거하는 커밋 명령에 포함됩니다.
나뭇가지. 이 명령은 내부 분기 구조를 재설정하여 파일이 없도록 합니다.
프런트엔드가 이후에 흥미로운 모든 파일을 처음부터 추가할 수 있도록 허용합니다.
'모두 삭제'LF
이 명령은 프런트엔드가 알지 못하는 경우(또는 관심이 없는 경우) 매우 유용합니다.
알고 있음) 현재 지점에 어떤 파일이 있어서 적절한 파일을 생성할 수 없는지
내용을 업데이트하는 filedelete 명령입니다.
fileleteall을 실행한 후 올바른 파일을 설정하기 위해 필요한 filemodify 명령을 실행합니다.
콘텐츠는 필요한 파일만 보내는 것과 동일한 결과를 생성합니다.수정 및
filedelete 명령. 그러나 filedeleteall 접근 방식을 사용하려면 빠른 가져오기가 필요할 수 있습니다.
활성 분기당 약간 더 많은 메모리(대부분의 대규모 프로젝트에서도 1MiB 미만)
따라서 커밋에 영향을 받는 경로만 쉽게 얻을 수 있는 프런트엔드는 다음과 같습니다.
그렇게 하도록 권장합니다.
메모수정
커밋에 포함됨 주석을 추가하는 새 메모를 추가하는 명령
또는 이 주석 내용을 변경하세요. 내부적으로는 filemodify 100644와 유사합니다.
경로(하위 디렉터리로 분할될 수도 있음) 다른 것을 사용하는 것은 권장되지 않습니다
쓰기 명령 filedeleteall을 제외한 트리는 기존의 모든 항목을 삭제합니다.
이 나무에 메모가 있습니다. 이 명령에는 내용을 지정하는 두 가지 방법이 있습니다.
메모.
외부 데이터 형식
메모의 데이터 콘텐츠는 이전 blob 명령에 의해 이미 제공되었습니다. 그만큼
프런트엔드는 주석을 추가할 커밋에 연결하기만 하면 됩니다.
'N'SP SP LF
여기 마크 참조(: ) 이전 blob에 의해 설정됨
명령 또는 기존 Git blob 객체의 전체 40바이트 SHA-1입니다.
인라인 데이터 형식
메모의 데이터 콘텐츠가 아직 제공되지 않았습니다. 프론트엔드가 원하는 것
이 수정 명령의 일부로 이를 제공하십시오.
'N' SP '인라인' SP LF
데이터
data 명령에 대한 자세한 설명은 아래를 참조하세요.
두 형식 모두 커밋 사양 표현식 중 하나입니다.
from(위 참조)에서 수락합니다.
표
현재 개체에 대한 참조를 저장하기 위해 빠른 가져오기를 준비하여 프런트엔드를 허용합니다.
SHA-1을 알지 못한 채 미래 시점에 이 객체를 호출합니다. 여기서는
현재 객체는 mark 명령이 나타나는 객체 생성 명령입니다. 이것은 될 수있다
커밋, 태그 및 blob이 있지만 커밋이 가장 일반적으로 사용됩니다.
'마크' SP ':' LF
어디 프런트엔드에서 이 표시에 할당한 번호입니다. 의 가치 ~이다
ASCII 십진 정수로 표현됩니다. 값 0은 예약되어 있으므로 사용할 수 없습니다.
표시. 1보다 크거나 같은 값만 표시로 사용할 수 있습니다.
새 마크가 자동으로 생성됩니다. 기존 마크를 다른 객체로 간단히 이동할 수 있습니다.
같은 것을 재사용함으로써 다른 표시 명령에서.
태그
특정 커밋을 참조하는 주석이 달린 태그를 생성합니다. 가볍게 만들려면
(주석이 없는) 태그는 아래의 재설정 명령을 참조하세요.
'태그' SP LF
'에서' SP LF
'태거'(SP )? SP LT GT SP LF
데이터
어디 생성할 태그의 이름입니다.
태그 이름은 Git에 저장될 때 자동으로 refs/tags/ 접두사가 붙습니다.
CVS 분기 기호 RELENG-1_0-FINAL은 RELENG-1_0-FINAL만 사용합니다. , 그리고
fast-import는 해당 참조를 refs/tags/RELENG-1_0-FINAL로 작성합니다.
의 가치 Git에서 유효한 참조 이름이어야 하므로 다음을 포함할 수 있습니다.
슬래시. Git 참조 이름에서는 LF가 유효하지 않으므로 인용 또는 이스케이프 구문이 지원되지 않습니다.
여기를 클릭해 문의해주세요.
from 명령은 commit 명령과 동일합니다. 자세한 내용은 위를 참조하세요.
tagger 명령은 커밋 내의 커미터와 동일한 형식을 사용합니다. 다시 위 내용을 참조하세요
세부.
태거 뒤에 오는 데이터 명령은 주석이 달린 태그 메시지를 제공해야 합니다(자세한 내용은 아래 참조).
데이터 명령 구문). 빈 태그 메시지를 가져오려면 길이가 0인 데이터를 사용하세요. 태그 메시지는
자유 형식이며 Git에서 해석되지 않습니다. 현재는 UTF-8로 인코딩되어야 합니다.
fast-import는 다른 인코딩 지정을 허용하지 않습니다.
fast-import 내에서 가져오는 동안 주석이 달린 태그에 서명하는 것은 지원되지 않습니다. 하려고
자신의 PGP/GPG 서명을 포함하는 것은 권장되지 않습니다. 프런트엔드에서는 (쉽게) 그렇지 않기 때문입니다.
일반적으로 그러한 서명에 들어가는 전체 바이트 세트에 액세스할 수 있습니다. 만약에
서명이 필요합니다. 재설정을 통해 빠른 가져오기 내에서 경량 태그를 생성한 다음
표준을 사용하여 해당 태그의 주석이 달린 버전을 오프라인으로 생성 자식 태그 프로세스.
재설정
선택적으로 특정 개정에서 시작하여 명명된 분기를 생성(또는 다시 생성)합니다. 그만큼
재설정 명령을 사용하면 프런트엔드가 기존 분기에 대해 새로운 from 명령을 실행하거나
새 커밋을 만들지 않고 기존 커밋에서 새 브랜치를 만듭니다.
SP '재설정' LF
('에서' SP LF)?
LF?
자세한 설명은 그리고 위의 커밋 및 출처를 참조하세요.
명령 뒤의 LF는 선택 사항입니다(예전에는 필수였습니다).
재설정 명령을 사용하여 주석이 없는 경량 태그를 생성할 수도 있습니다. 을 위한
예:
참조/태그/938 재설정
:938에서
커밋 마크 :938을 참조하는 경량 태그 refs/tags/938을 생성합니다.
참조.
윤곽이 흐릿한 것
Packfile에 하나의 파일 개정판 쓰기를 요청합니다. 개정이 어떤 항목에도 연결되어 있지 않습니다.
저지르다; 이 연결은 후속 커밋 명령에서 다음을 참조하여 형성되어야 합니다.
할당된 마크를 통해 블롭합니다.
'블롭'LF
표시?
데이터
일부 프런트엔드가 Git SHA-1을 생성하도록 선택했으므로 여기서 mark 명령은 선택 사항입니다.
Blob을 자체적으로 처리하고 커밋하기 위해 직접 공급합니다. 이는 일반적으로 더 많은 작업입니다.
그러나 마크는 저장 비용이 저렴하고 사용하기 쉽기 때문에 그만한 가치가 있습니다.
데이터
원시 데이터 제공(BLOB/파일 콘텐츠, 커밋 메시지 또는 주석이 달린 태그로 사용)
메시지)를 빠르게 가져옵니다. 데이터는 정확한 바이트 수를 사용하여 제공되거나 다음으로 구분될 수 있습니다.
종료 라인. 프로덕션 품질 변환을 위한 실제 프런트엔드는 다음과 같습니다.
더 강력하고 더 나은 성능을 발휘하므로 항상 정확한 바이트 수 형식을 사용하세요. 그만큼
구분 형식은 주로 빠른 가져오기 테스트를 위한 것입니다.
내에 나타나는 주석 줄 데이터 명령의 일부는 항상 일부로 간주됩니다.
데이터 본문의 일부이므로 빠른 가져오기에서는 절대 무시되지 않습니다. 이렇게 하면 안전해진다
#으로 시작하는 줄이 있는 파일/메시지 내용을 가져옵니다.
정확한 바이트 수 형식
프런트엔드는 데이터 바이트 수를 지정해야 합니다.
'데이터' SP LF
LF?
어디 안에 나타나는 정확한 바이트 수입니다. . 의 가치
ASCII 십진 정수로 표현됩니다. 양쪽에 있는 LF ~이다
포함되지 않음 가져온 데이터에는 포함되지 않습니다.
LF 이후 선택 사항(이전에는 필수)이지만 권장됩니다. 언제나
이를 포함하면 다음 명령이 항상 그렇듯이 빠른 가져오기 스트림 디버깅이 더 쉬워집니다.
다음 줄의 0열에서 시작합니다. LF로 끝나지 않았습니다.
구분 형식
구분 기호 문자열은 데이터의 끝을 표시하는 데 사용됩니다. fast-import는 다음을 계산합니다.
구분 기호를 검색하여 길이를 지정합니다. 이 형식은 주로 테스트 및
실제 데이터에는 권장되지 않습니다.
'데이터' SP '<<' LF
LF
LF
LF?
어디 선택한 구분 기호 문자열입니다. 문자열 에 나타나서는 안 됩니다.
그 자체로 라인 그렇지 않으면 빠른 가져오기는 데이터가 더 일찍 끝나는 것으로 생각합니다.
실제보다. LF가 즉시 뒤따른다 의 일부입니다 . 이것은 하나입니다
구분 형식의 한계로 인해 데이터 청크를 제공하는 것은 불가능합니다.
마지막 바이트로 LF가 없습니다.
이후 LF LF는 선택 사항입니다(예전에는 필수였습니다).
체크 포인트
현재 팩 파일을 닫고 새 팩 파일을 시작하고 모든 파일을 저장하도록 강제로 빠른 가져오기를 수행합니다.
현재 분기 참조, 태그 및 마크.
'체크포인트' LF
LF?
fast-import는 현재 팩 파일이 도달하면 자동으로 팩 파일을 전환합니다.
--max-pack-size 또는 4GiB 중 더 작은 제한. 자동 팩파일 전환 중
fast-import는 브랜치 참조, 태그 또는 마크를 업데이트하지 않습니다.
체크포인트에는 상당한 양의 CPU 시간과 디스크 IO가 필요할 수 있으므로(
전체 팩 SHA-1 체크섬, 해당 인덱스 파일 생성 및 참조 업데이트)
단일 체크포인트 명령을 완료하는 데 몇 분이 걸릴 수 있습니다.
프런트엔드는 매우 크고 장기간 실행되는 가져오기 중에 체크포인트를 발행하도록 선택할 수 있습니다.
또는 다른 Git 프로세스가 브랜치에 액세스하도록 허용해야 하는 경우. 그러나 30이라는 점을 감안할 때
GiB Subversion 저장소는 빠른 가져오기를 통해 약 3시간 만에 Git에 로드할 수 있으며,
명시적인 체크포인트가 필요하지 않을 수도 있습니다.
명령 뒤의 LF는 선택 사항입니다(예전에는 필수였습니다).
진행
fast-import가 수정되지 않은 전체 진행 라인을 표준 출력으로 인쇄하도록 합니다.
명령이 입력 스트림에서 처리될 때 채널(파일 설명자 1)입니다. 그만큼
그렇지 않으면 명령은 현재 가져오기 또는 fast-import의 내부 가져오기에 영향을 미치지 않습니다.
(주).
'진행' SP LF
LF?
그만큼 명령의 일부에는 LF를 포함하지 않는 바이트 시퀀스가 포함될 수 있습니다.
명령 뒤의 LF는 선택 사항입니다. 호출자는 다음을 통해 출력을 처리하기를 원할 수 있습니다.
sed와 같은 도구를 사용하여 줄의 앞 부분을 제거합니다. 예를 들면 다음과 같습니다.
프론트엔드 | 자식 빠른 가져오기 | sed 's/^진행 //'
체크포인트 바로 뒤에 진행 명령을 놓으면 리더에게 다음 시점을 알립니다.
체크포인트가 완료되었으며 빠른 가져오기 업데이트가 적용된 참조에 안전하게 액세스할 수 있습니다.
마크 획득
빠른 가져오기를 통해 표시에 해당하는 SHA-1을 표준 출력 또는 파일로 인쇄합니다.
설명자는 이전에 --cat-blob-fd 인수로 정렬되었습니다. 그렇지 않으면 명령에
현재 가져오기에는 영향이 없습니다. 그 목적은 나중에 커밋하는 SHA-1을 검색하는 것입니다.
커밋 메시지에서 참조하고 싶을 수도 있습니다.
'get-mark' SP ':' LF
이 명령은 주석이 허용되는 스트림의 어느 곳에서나 사용할 수 있습니다. 특히,
get-mark 명령은 커밋 중간에 사용할 수 있지만 데이터 중간에는 사용할 수 없습니다.
명령.
이 출력을 안전하게 읽는 방법에 대한 자세한 내용은 아래 "명령에 대한 응답"을 참조하세요.
고양이 덩어리
fast-import가 이전에 배열된 파일 설명자로 blob을 인쇄하도록 합니다.
--cat-blob-fd 인수. 그렇지 않으면 명령은 현재 가져오기에 영향을 주지 않습니다. 그것은
주요 목적은 fast-import의 메모리에 있지만 액세스할 수 없는 blob을 검색하는 것입니다.
대상 저장소에서.
'cat-blob' SP LF
그만큼 마크 참조(: ) 이전에 설정되었거나 전체 40바이트
이미 존재하거나 작성 준비가 된 Git blob의 SHA-1입니다.
출력은 git cat-file --batch와 동일한 형식을 사용합니다.
SP '블롭' SP LF
LF
이 명령은 주석이 허용되는 스트림의 어느 곳에서나 사용할 수 있습니다. 특히,
cat-blob 명령은 커밋 중간에 사용할 수 있지만 데이터 중간에는 사용할 수 없습니다.
명령.
이 출력을 안전하게 읽는 방법에 대한 자세한 내용은 아래 "명령에 대한 응답"을 참조하세요.
ls
이전에 정렬된 파일 설명자의 경로에 있는 객체에 대한 정보를 인쇄합니다.
--cat-blob-fd 인수를 사용합니다. 이를 통해 활성 커밋에서 blob을 인쇄할 수 있습니다(
cat-blob) 또는 현재 커밋에 사용하기 위해 이전 커밋의 blob 또는 트리를 복사합니다.
(파일 수정 포함).
ls 명령은 다음을 포함하여 주석이 허용되는 스트림의 어느 곳에서나 사용할 수 있습니다.
커밋 중간.
활성 커밋에서 읽기
이 양식은 커밋 중에만 사용할 수 있습니다. 경로는 디렉토리 항목의 이름을 지정합니다.
fast-import의 활성 커밋 내에서. 이 경우 경로를 인용해야 합니다.
'ls' SP LF
명명된 트리에서 읽기
그만큼 마크 참조가 될 수 있습니다(: ) 또는 Git의 전체 40바이트 SHA-1
태그, 커밋 또는 트리 개체가 이미 존재하거나 작성 대기 중입니다. 경로는
이름이 지정된 트리의 최상위 레벨을 기준으로 .
'ls' SP SP LF
자세한 설명은 위의 filemodify를 참조하세요. .
출력은 git ls-tree와 동일한 형식을 사용합니다. -- :
SP ('blob' | '트리' | '커밋') SP HT LF
그만큼 blob, 트리 또는 커밋 개체를 나타냅니다. 다음에서 사용할 수 있습니다.
후에 마크 획득, 고양이 덩어리, 파일수정및 ls 명령.
해당 경로에 파일이나 하위 트리가 없으면 자식 빠른 가져오기 대신 보고할게
SP 누락 LF
이 출력을 안전하게 읽는 방법에 대한 자세한 내용은 아래 "명령에 대한 응답"을 참조하세요.
기능
빠른 가져오기가 지정된 기능을 지원하도록 요구하거나 지원하지 않는 경우 중단합니다.
'기능' SP ('=' )? LF
그만큼 명령의 일부는 다음 중 하나일 수 있습니다.
날짜 형식, 수출 표시, 상대 표시, 상대 표시 없음, 강제
선행 문자가 있는 해당 명령줄 옵션인 것처럼 작동합니다. -- 전달되었다
명령줄(위의 옵션 참조)
수입 표시, 존재하는 경우 수입 표시
두 가지 측면을 제외하고 --import-marks와 같습니다. 첫째, 단 하나의 "feature import-marks" 또는
"feature import-marks-if-exists" 명령은 스트림별로 허용됩니다. 둘째,
--import-marks= 또는 --import-marks-if-exists 명령줄 옵션은 다음 중 하나를 재정의합니다.
스트림의 "기능" 명령; 세 번째, "import-marks-if-exists 기능"
해당 명령줄 옵션은 존재하지 않는 파일을 자동으로 건너뜁니다.
get-mark, cat-blob, ls
백엔드가 다음을 지원하도록 요구합니다. 마크 획득, 고양이 덩어리및 ls 각각 명령을 내립니다.
지정된 명령을 지원하지 않는 빠른 가져오기 버전은 메시지와 함께 종료됩니다.
그렇게 표시합니다. 이렇게 하면 가져오기 오류를 명확한 메시지로 조기에 처리할 수 있습니다.
지원되지 않는 명령이 실행되기 전에 가져오기 초기 부분에서 시간 낭비
감지되었습니다.
노트
백엔드가 다음을 지원하도록 요구합니다. 메모수정 (N) 하위 명령을 범하다 명령.
노트를 지원하지 않는 빠른 가져오기 버전은 이를 알리는 메시지와 함께 종료됩니다.
한
스트림이 없이 종료되면 오류가 발생합니다. 한 명령. 이 기능이 없으면 오류가 발생합니다.
스트림의 편리한 지점에서 프런트엔드가 갑자기 종료되도록 하면
감지되지 않았습니다. 예를 들어 가져오기 프런트 엔드가 작업 도중에 종료되는 경우 이러한 현상이 발생할 수 있습니다.
하위 git fast-import 인스턴스에서 SIGTERM 또는 SIGKILL을 내보내지 않고.
선택권
git fast-import가 적합한 방식으로 작동하도록 지정된 옵션을 처리합니다.
프론트엔드의 요구 사항. 프런트엔드에서 지정한 옵션은 다음 옵션에 의해 재정의됩니다.
사용자가 git fast-import 자체를 지정할 수 있는 옵션입니다.
'옵션' SP LF
그만큼 명령의 일부에는 OPTIONS에 나열된 옵션이 포함될 수 있습니다.
가져오기 의미를 변경하지 않는 섹션 -- 그리고 다음과 같은 곳에서 치료를 받습니다.
같은 길.
옵션 명령은 입력의 첫 번째 명령이어야 합니다(기능 명령은 계산하지 않음).
옵션이 아닌 명령 다음에 옵션 명령을 제공하는 것은 오류입니다.
다음 명령줄 옵션은 가져오기 의미를 변경하므로 전달되지 않을 수 있습니다.
옵션으로:
· 날짜 형식
· 수입마크
· 수출마크
· 고양이-blob-fd
· 힘
한
완료 기능을 사용하지 않는 경우 EOF를 읽은 것처럼 처리됩니다. 이것은 다음과 같이 말할 수 있습니다.
빠른 가져오기를 통해 일찍 완료하세요.
--done 명령줄 옵션 또는 기능 완료 명령을 사용 중인 경우 완료 명령은 다음과 같습니다.
필수이며 스트림의 끝을 표시합니다.
응답 ~까지 명령
빠른 가져오기로 작성된 새 개체는 즉시 사용할 수 없습니다. 가장 빠른 수입
명령은 다음 체크포인트(또는 완료)까지 시각적 효과가 없습니다. 프런트엔드
얼마나 빨리 가져오는지에 대해 걱정하지 않고 fast-import의 입력 파이프를 채우는 명령을 보낼 수 있습니다.
스케줄링을 단순화하여 성능을 향상시킵니다.
하지만 일부 프런트엔드의 경우 현재 프런트엔드에서 데이터를 다시 읽을 수 있는 것이 유용합니다.
업데이트되는 저장소(예: 소스 자료가 객체를 설명하는 경우)
이전에 가져온 개체에 적용할 패치 측면에서). 이것은 될 수있다
양방향 파이프를 통해 프런트엔드와 빠른 가져오기를 연결하여 수행됩니다.
mkfifo 빠른 가져오기 출력
프런트엔드
git fast-import>빠른 가져오기-출력
이런 방식으로 설정된 프런트엔드는 Progress, get-mark, ls 및 cat-blob 명령을 사용하여 읽을 수 있습니다.
진행 중인 가져오기 정보입니다.
교착 상태를 방지하려면 이러한 프런트엔드는 다음에서 보류 중인 출력을 완전히 소비해야 합니다.
빠른 가져오기에 쓰기를 수행하기 전에 Progress, ls, get-mark 및 cat-blob을 실행하세요.
블록.
추락 보고서
fast-import가 잘못된 입력으로 제공되면 XNUMX이 아닌 종료 상태로 종료되며
가져온 Git 저장소의 최상위 수준에 충돌 보고서를 만듭니다. 충돌
보고서에는 내부 빠른 가져오기 상태의 스냅샷과 최신 정보가 포함됩니다.
충돌로 이어지는 명령.
모든 최근 명령(스트림 주석, 파일 변경 및 진행 명령 포함)은
충돌 보고서 내의 명령 기록에 표시되지만 원시 파일 데이터와 커밋
메시지는 충돌 보고서에서 제외됩니다. 이렇게 제외하면 보고서 내 공간이 절약됩니다.
실행 중에 빠른 가져오기가 수행해야 하는 버퍼링 양을 줄입니다.
충돌 보고서를 작성한 후 빠른 가져오기는 현재 팩 파일을 닫고
마크 테이블. 이를 통해 프런트엔드 개발자는 저장소 상태를 검사하고 재개할 수 있습니다.
충돌이 발생한 지점에서 가져오기. 수정된 분기 및 태그는 업데이트되지 않습니다.
충돌 중에 가져오기가 성공적으로 완료되지 않았기 때문입니다. 지점 및 태그 정보
충돌 보고서에서 찾을 수 있으며 업데이트가 필요한 경우 수동으로 적용해야 합니다.
충돌 예:
$ 고양이 ><에서
# 나의 첫 번째 테스트 커밋
참조/헤드/마스터 커밋
커미터 숀 O. 피어스 19283 -0400
# 저 사람은 누구야?
데이터 <
이건 내 커밋이야
EOF
M 644 인라인 .gitignore
데이터 <
.gitignore
EOF
M 777 인라인 밥
END_OF_INPUT
$ git 빠른 가져오기
치명적: 손상 모드: M 777 인라인 bob
fast-import: 충돌 보고서를 .git/fast_import_crash_8434에 덤프합니다.
$ 고양이 .git/fast_import_crash_8434
빠른 가져오기 충돌 보고서:
빠른 가져오기 프로세스: 8434
상위 프로세스 : 1391
1년 00월 58일 토요일 12:2007:XNUMX
치명적: 손상 모드: M 777 인라인 bob
충돌 전 가장 최근 명령
---------------------------------
# 나의 첫 번째 테스트 커밋
참조/헤드/마스터 커밋
커미터 숀 O. 피어스 19283 -0400
# 저 사람은 누구야?
데이터 <
M 644 인라인 .gitignore
데이터 <
* M 777 인라인 밥
활성 분기 LRU
-----------------
active_branches = 현재 1개, 최대 5개
POS 시계 이름
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 참조 0개/헤드/마스터
비활성 지점
-----------------
심판/헤드/마스터:
상태 : 활성 로드된 더티
팁 커밋 : 0000000000000000000000000000000000000000
오래된 나무 : 0000000000000000000000000000000000000000
커 트리 : 0000000000000000000000000000000000000000
커밋 클럭: 0
마지막 팩:
-------------------
충돌 보고서 끝
팁 및 트릭
다음은 빠른 가져오기의 다양한 사용자로부터 수집한 팁과 요령입니다.
여기에 제안 사항이 제공됩니다.
한 표시 당 커밋
저장소 변환을 수행할 때 커밋당 고유한 표시를 사용합니다(mark : ) 및 공급
명령줄의 --export-marks 옵션. fast-import는 다음을 나열하는 파일을 덤프합니다.
모든 마크와 그에 상응하는 Git 객체 SHA-1. 프런트엔드가
소스 저장소에 다시 표시하면 정확성과 완전성을 쉽게 확인할 수 있습니다.
각 Git 커밋을 해당 소스 개정과 비교하여 가져옵니다.
Perforce 또는 Subversion과 같은 시스템에서 오는 것은 매우 간단합니다.
fast-import 표시는 Perforce 변경 세트 번호 또는 Subversion 개정일 수도 있습니다.
수.
자유로이 건너뛰기 주위에 지점
작업 중에 한 번에 하나의 브랜치만 유지하도록 프런트엔드를 최적화하려고 애쓰지 마세요.
수입. 그렇게 하면 빠른 가져오기의 경우 약간 더 빨라질 수 있지만 증가하는 경향이 있습니다.
프론트엔드 코드의 복잡성이 상당히 높습니다.
빠른 가져오기를 위해 내장된 분기 LRU는 매우 잘 작동하는 경향이 있으며,
비활성 분기를 활성화하는 것이 너무 낮아서 분기 사이를 돌아다니는 것이
가져오기 성능에는 거의 영향을 미치지 않습니다.
처리 이름 바꾸기
이름이 바뀐 파일이나 디렉터리를 가져올 때 이전 이름을 삭제하고
해당 커밋 중 새 이름. Git은 사후에 이름 변경 감지를 수행합니다.
커밋 중에 명시적으로 하는 것이 아니라
꼬리표 해결하다 지점
일부 다른 SCM 시스템에서는 사용자가 원본이 아닌 여러 파일에서 태그를 생성할 수 있습니다.
동일한 커밋/변경 세트. 또는 다음에서 사용 가능한 파일의 하위 집합인 태그를 생성하려면
저장소.
최소한 하나의 커밋을 하지 않으면 Git에서 이러한 태그를 있는 그대로 가져오는 것이 불가능합니다.
태그의 내용과 일치하도록 파일을 "수정"합니다. fast-import의 재설정 명령을 사용하여
일반 분기 공간 외부의 더미 분기를 태그의 기본 커밋으로 재설정합니다.
그런 다음 하나 이상의 파일 수정 커밋을 커밋하고 마지막으로 더미 분기에 태그를 지정합니다.
예를 들어 모든 일반 브랜치는 refs/heads/ 아래에 저장되므로 태그 이름을 fixup으로 지정합니다.
브랜치 TAG_FIXUP. 이렇게 하면 수입자가 사용하는 Fixup 분기가 다음을 수행하는 것이 불가능합니다.
소스에서 가져온 실제 분기(TAG_FIXUP 이름)와 네임스페이스 충돌이 있습니다.
심판/헤드/TAG_FIXUP이 아닙니다).
수정 사항을 커밋할 때 병합을 사용하여 제공되는 커밋을 연결하는 것을 고려하세요.
Fixup 분기에 대한 파일 개정. 그렇게 하면 다음과 같은 도구가 허용됩니다. 자식 비난 추적하다
실제 커밋 기록을 통해 소스 파일에 적절하게 주석을 추가합니다.
빠른 가져오기가 종료된 후 프런트엔드는 rm .git/TAG_FIXUP을 수행하여
더미 지점.
수입 지금, Repack 후
빠른 가져오기가 완료되면 Git 저장소가 완전히 유효해지고 사용할 준비가 됩니다.
일반적으로 이는 상당히 큰 프로젝트의 경우에도 매우 짧은 시간만 소요됩니다.
(100,000개 이상의 커밋).
그러나 데이터 지역성과 액세스를 향상하려면 저장소를 다시 포장해야 합니다.
성능. 매우 큰 프로젝트에서는 몇 시간이 걸릴 수도 있습니다(특히 -f와 a가 있는 경우).
큰 --window 매개변수가 사용됩니다). 재포장은 독자와 함께 실행하는 것이 안전하기 때문에
작가 여러분, 백그라운드에서 리팩을 실행하고 완료되면 완료되도록 하세요. 없다
새로운 Git 프로젝트를 탐색하기 위해 기다려야 할 이유가 있습니다!
재포장을 기다리기로 선택한 경우 벤치마크나 성능 테스트를 실행하지 마세요.
재포장이 완료될 때까지. fast-import는 단순히 차선책인 팩 파일을 출력합니다.
실제 사용 상황에서는 본 적이 없습니다.
재포장 역사적인 Data
매우 오래된 가져온 데이터(예: 작년보다 오래된 데이터)를 다시 압축하는 경우 다음을 고려하십시오.
추가 CPU 시간을 확장하고 실행할 때 --window=50(또는 그 이상)을 제공합니다. 자식
재 포장하다. 이 작업은 시간이 더 오래 걸리지만 더 작은 팩 파일도 생성됩니다. 당신은 단지
한 번만 노력하면 프로젝트를 사용하는 모든 사람이 더 작은 혜택을 누릴 수 있습니다.
저장소.
포함 일부 진행 메시지
가끔씩 프런트엔드에서 빠른 가져오기에 대한 진행 메시지를 내보내도록 하세요. 그만큼
메시지의 내용은 완전히 자유 형식이므로 한 가지 제안은 다음을 출력하는 것입니다.
현재 커밋 날짜가 다음 달로 이동할 때마다 현재 월 및 연도입니다. 당신의
사용자는 처리된 데이터 스트림의 양을 더 잘 알 수 있습니다.
팩파일 최적화
Blob을 패킹할 때 빠른 가져오기는 항상 작성된 마지막 Blob에 대해 삭제를 시도합니다.
프런트엔드에서 특별히 지정하지 않는 한 이는 아마도 사전에 발생하지 않을 것입니다.
동일한 파일 버전이므로 생성된 델타는 가능한 가장 작지 않습니다. 그만큼
결과 팩 파일은 압축되지만 최적은 아닙니다.
단일 파일의 모든 개정판에 효율적으로 액세스할 수 있는 프런트엔드(예:
RCS/CVS,v 파일 읽기) 해당 파일의 모든 개정판을 시퀀스로 제공하도록 선택할 수 있습니다.
연속적인 blob 명령. 이를 통해 빠른 가져오기를 통해 다른 파일을 삭제할 수 있습니다.
개정판을 서로 비교하여 최종 팩 파일의 공간을 절약합니다. 마크는 다음과 같은 용도로 사용할 수 있습니다.
나중에 일련의 커밋 명령 중에 개별 파일 개정을 식별합니다.
fast-import로 생성된 팩파일은 양호한 디스크 액세스 패턴을 권장하지 않습니다. 이것은
표준 입력에서 수신된 순서대로 데이터를 쓰는 빠른 가져오기로 인해 발생합니다.
Git은 일반적으로 가장 최근(현재 팁)을 만들기 위해 팩파일 내에 데이터를 구성합니다.
데이터는 과거 데이터보다 먼저 나타납니다. Git은 또한 클러스터 커밋을 함께 수행하여 속도를 높입니다.
더 나은 캐시 지역성을 통한 개정 순회.
이러한 이유로 사용자는 git으로 저장소를 다시 압축하는 것이 좋습니다.
빠른 가져오기가 완료된 후 -a -d를 다시 압축하면 Git이 다음에 대한 팩 파일을 재구성할 수 있습니다.
더 빠른 데이터 액세스. 블롭 델타가 최적이 아닌 경우(위 참조) -f도 추가합니다.
모든 델타를 강제로 다시 계산하는 옵션을 사용하면 최종 팩 파일을 크게 줄일 수 있습니다.
크기(30-50% 더 작은 것이 일반적일 수 있음).
메모리 이용
빠른 가져오기를 수행하는 데 필요한 메모리 양에 영향을 미치는 여러 가지 요소가 있습니다.
수입. 핵심 Git의 중요한 섹션과 마찬가지로 빠른 가져오기는 자체 메모리 할당자를 사용합니다.
malloc과 관련된 오버헤드를 상각합니다. 실제로 빠른 가져오기는 다음과 같은 경향이 있습니다.
대규모 블록 할당을 사용하므로 모든 malloc 오버헤드를 0으로 상각합니다.
용 대상
fast-import는 이 실행에서 작성된 모든 객체에 대해 메모리 내 구조를 유지합니다.
32비트 시스템에서 구조는 32바이트이고, 64비트 시스템에서 구조는 40바이트입니다.
(포인터 크기가 더 크기 때문에). 테이블의 개체는 다음까지 할당이 취소되지 않습니다.
빠른 가져오기가 종료됩니다. 2비트 시스템에서 32백만 개의 개체를 가져오려면 다음이 필요합니다.
약 64MiB의 메모리.
객체 테이블은 실제로 객체 이름(고유 SHA-1)을 기반으로 하는 해시테이블입니다. 이것
스토리지 구성을 통해 기존 또는 이미 작성된 객체를 재사용할 수 있는 빠른 가져오기 가능
출력 팩 파일에 중복 항목을 쓰지 마십시오. 중복된 얼룩은 놀랍게도
일반적으로 소스의 분기 병합으로 인해 가져오기에서 일반적입니다.
용 표
마크는 1개의 포인터(4바이트 또는 8바이트)를 사용하여 희소 배열에 저장됩니다.
포인터 크기) 마크당. 배열은 희박하지만 프런트엔드는 여전히 강력합니다.
1과 n 사이의 점수를 사용하도록 권장됩니다. 여기서 n은 요구되는 총 점수 수입니다.
이번 수입.
용 지사
분기는 활성 및 비활성으로 분류됩니다. 두 클래스의 메모리 사용량은 다음과 같습니다.
상당히 다릅니다.
비활성 분기는 96 또는 120바이트(32비트 또는 64비트)를 사용하는 구조에 저장됩니다.
시스템) 및 분기 이름 길이(일반적으로 200바이트 미만),
지점마다. fast-import는 10,000분 안에 최대 2개의 비활성 분기를 쉽게 처리합니다.
MiB의 메모리.
활성 분기에는 비활성 분기와 동일한 오버헤드가 있지만
해당 가지에서 최근 수정된 모든 트리. 하위 트리 포함이 이루어지지 않은 경우
브랜치가 활성화된 이후 수정된 내용은 메모리에 로드되지 않지만
분기가 활성화된 이후 하위 트리 src가 커밋에 의해 수정된 경우 해당
내용이 메모리에 로드됩니다.
활성 브랜치는 해당 브랜치에 포함된 파일에 대한 메타데이터를 저장하므로
메모리 내 저장소 크기는 상당히 커질 수 있습니다(아래 참조).
fast-import는 간단한 명령에 따라 자동으로 활성 분기를 비활성 상태로 이동합니다.
가장 최근에 사용된 알고리즘. LRU 체인은 커밋 명령마다 업데이트됩니다. 그만큼
명령줄에서 최대 활성 분기 수를 늘리거나 줄일 수 있습니다.
--활성-분기=.
용 활동적인 나무
트리(디렉터리라고도 함)는 필요한 메모리 외에 12바이트의 메모리만 사용합니다.
해당 항목(아래 "활성 파일별" 참조) 나무의 비용은 사실상 0이다.
오버헤드는 개별 파일 항목에 대해 상각됩니다.
용 활동적인 파일 항목
활성 트리 내의 파일(및 하위 트리에 대한 포인터)에는 52 또는 64바이트(32/64비트)가 필요합니다.
플랫폼) 항목당. 공간을 절약하기 위해 파일 및 트리 이름은 공통 문자열로 풀링됩니다.
테이블에서 파일 이름 "Makefile"이 16바이트만 사용하도록 허용합니다(문자열 포함 후).
헤더 오버헤드) 프로젝트 내에서 몇 번이나 발생하든 상관없습니다.
파일 이름 문자열 풀 및 지연 로딩과 결합된 활성 분기 LRU
하위 트리를 사용하면 빠른 가져오기를 통해 2,000개 이상의 분기가 있는 프로젝트를 효율적으로 가져올 수 있습니다.
매우 제한된 메모리 공간(활성 분기당 45,114MiB 미만)에 2.7개 이상의 파일이 있습니다.
신호
보내기 시구스르1 ~로 자식 빠른 가져오기 프로세스는 현재 팩파일을 일찍 종료하고 시뮬레이션합니다.
체크포인트 명령. 참을성이 없는 운영자는 이 기능을 사용하여 물체를 엿볼 수 있습니다.
실행 시간이 추가되거나 더 나쁜 비용을 들여 진행 중인 가져오기에서 참조를 수행합니다.
압축.
onworks.net 서비스를 사용하여 온라인으로 git-fast-import 사용
