로컬에서 커밋하려면 왜 ikiwiki에 3개의 git 저장소가 필요한가요?

로컬에서 커밋하려면 왜 ikiwiki에 3개의 git 저장소가 필요한가요?

로컬이 있는 경우iQiWiki내 랩톱에서는 "repository" 디렉터리( mywiki.git기본 저장소), "scrdir"( myikigit 저장소) 및 생성된 html 파일이 있는 위치("destdir")가 필요합니다. 로컬 웹 브라우저에서는 올바르게 실행됩니다.

그러나 명령줄에서 텍스트 편집기와 git도 사용하려면 세 번째 git 저장소 mywiki.local("작업 복제본")를 설정해야 합니다. 다음 그림과 같이 scrdir로 푸시하고 html 페이지를 다시 작성하는 후크를 mywiki.git트리거하는 푸시 되는 항목은 다음과 같습니다 .post-update

작업 과정

이 접근 방식을 사용하면위키를 실행하기 위해 내 노트북에 있는 디렉토리와 거의 동일한 디렉토리입니다. 즉, 디스크 공간을 한 번이 아닌 세 배나 차지합니다.

그 이유는 무엇입니까?

하나의 컴퓨터에서만 작업하는 경우 이를 방지할 수 있는 안전한 방법이 있습니까? 두 개 또는 더 나은 하나의 디렉터리로 줄이는 방법이 있습니까?

답변1

너무 많은 것 같습니다. 하나의 Git 저장소만 처리할 수 있습니다. 그것은 모두 인프라의 기능에 달려 있습니다 ikiwiki(나는 그것에 대해 전혀 모릅니다).

저장소를 베어 저장소로 설정하려는 이유는 베어 저장소가 아닌 저장소에는 거의 항상 분기가 체크아웃되어 있기 때문입니다. 다른 git 리포지토리는 대상 리포지토리에서 체크아웃된 브랜치에 대한 커밋을 허용하지 않습니다(브랜치에서 작업하고 푸시가 컴퓨터에서 발생하며 파일이 코 밑에서 변경된다고 상상해 보세요).

srcdir"저장소"를 복제하는 대신 "저장소"에서 작업할 수도 있습니다 . 웹 편집과 동시에 파일을 수정할 수 있더라도 이로 인해 리소스 경합이 발생할 수 있습니다. 또한 수동으로 밀면 지저분해질 수 있으며 밀기도 발생합니다 ikiwiki.cgi. ikiwiki밀어서 실행하고 싶지 않은 후크를 넣을 수도 있습니다 . 그래서 그들은 "저장소"에서 복제하는 것이 좋습니다.

Git의 특징

로컬 머신에서 git 저장소를 복제하면 git은 중요한 최적화를 수행합니다. 이 옵션을 사용하면 --local(사용할 경우 기본값 git clone /path/to/repo) 공유하는 공통 기록에 대한 하드 링크를 사용하므로 디스크 공간이 절약됩니다. 다음은 발췌 내용입니다 git help clone.

   --local, -l
       When the repository to clone from is on a local machine,
       this flag bypasses the normal "Git aware" transport
       mechanism and clones the repository by making a copy of
       HEAD and everything under objects and refs directories.
       The files under .git/objects/ directory are hardlinked to
       save space when possible.

추가 디스크 공간은 .git/objects디렉터리가 아니라 체크아웃 자체에 있습니다. 이것이 여전히 너무 부담스럽다면 다른 솔루션으로 넘어가는 것이 좋습니다.

결론적으로

내부 작동 방식에 대해 많이 알지 않는 한 ikiwiki, 권장되는 설정 방법을 우회하려고 시도하지 않을 것입니다. 나는 이것이 안전하지 않다고 생각합니다. 더 나은 답변을 원하시면 이에 대해 더 많은 지식이 있는 더 나은 포럼으로 이동하실 수 있습니다 ikiwiki.

git이 내부 git 객체 파일에 대한 하드 링크를 수행한다는 사실을 알게 되면 사용된 추가 디스크 공간은 문제가 되지 않습니다.

답변2

나는 ikiwiki와 0개 이상의 저장소를 성공적으로 사용했습니다.

0..2는 단일 사용자이므로 아직 충돌이 발생하지 않았습니다. 0..1은 단지 ikiwiki의 실험일 뿐입니다.

내가 시도한 것은 다음과 같습니다.

  • 0개의 저장소 - 수동 컴파일,
  • 저장소 1개(작업 디렉터리 == srcdir), 업스트림 없음 - 수동 컴파일,
  • 2개의 저장소(작업 디렉터리 == srcdir + upstream)
  • 3개 이상의 저장소(서버의 위 2개 + NB의 원격 저장소)

3+에서는 다중 사용자로 전환할 예정이므로 더 흥미로울 것으로 예상됩니다.

나는 당신과 같은 질문에 대한 답변을 찾고 있습니다. 답변은 다음과 같습니다.

ikiwiki srcdir을 직접 편집하는 경우 동일한 파일을 web-ui로 편집하거나 다른 사용자가 기본 저장소로 푸시하면 충돌이 발생합니다.

srcdir에 제출하면 충돌은 web-ui에서 처리됩니다.

하지만커밋되지 않은 변경 사항파일로길을 잃을 것이다.

웹 편집 기능을 사용하지 않고 저장소에 커밋하는 다른 사용자가 없는 경우 저장소 2개를 사용할 수 있습니다. 1개라도 작동할 수 있습니다. 아니면 원격 저장소를 사용하세요.

또한 srcdir이 업데이트/재설정되기 전에 변경 사항을 저장하는 플러그인을 작성하는 것이 쉬울 것이라고 생각했습니다.

관련 정보