Por que eu preciso de 3 repositórios git para o ikiwiki se eu quiser me comprometer localmente?

Question

Se eu tiver um ikiwiki local no meu laptop eu preciso de um diretório "repositório" ( mywiki.git - um repositório vazio), um "scrdir" ( myiki a git repository) e um local onde os arquivos html produzidos vão ("destdir") para executá-lo corretamente a partir de um navegador da web localmente.

No entanto, se eu também quiser trabalhar com um editor de texto e git na linha de comando, eu preciso configurar um terceiro repositório git, que diga mywiki.local ("working clone"). Qual puhes para mywiki.git , que por sua vez aciona um gancho post-update para empurrar para o scrdir e reconstruir as páginas html, como ilustrado na figura a seguir:

Com essa abordagem, preciso de três diretórios quase idênticos no meu laptop apenas para executar um wiki, ou seja, ocupa três vezes o espaço em disco em vez de apenas uma vez.

Qual é a razão por trás disso?

Existe uma maneira segura de contornar isso se você está apenas trabalhando em uma máquina, para reduzi-la a apenas dois ou até mesmo um diretório?

    

Answer 1

Eu usei com sucesso o ikiwiki com 0+ repositórios.

0..2 são de usuário único, então não me deparo com conflitos (ainda). 0..1 eram apenas uma experiência com o ikiwiki.

Aqui está o que eu tentei:

• 0 repositórios - compilando manualmente,
• 1 repositório (diretório de trabalho == srcdir) sem upstream - compilando manualmente,
• 2 repositórios (diretório de trabalho == srcdir + upstream)
• 3+ repositórios (os 2 acima no servidor + remoto em um NB)

Com 3+ estamos indo multiusuário, então eu espero que seja mais interessante.

Eu estava procurando uma resposta para a mesma pergunta que a sua, então aqui está a resposta:

Se você estiver editando diretamente o ikiwiki srcdir, você terá um conflito se o mesmo arquivo for editado pelo web-ui (ou pressionado para repo por outros usuários).

Se você confirmar em srcdir, o conflito será tratado pela web-ui.

Mas todas as alterações não confirmadas no arquivo serão perdidas .

Se você não estiver usando o recurso de edição da web e não houver outros usuários comprometidos com o repositório, você estará bem com 2 repos. E até 1 pode funcionar. Ou 1 com repositório remoto.

Além disso, acho que seria fácil escrever um plugin para esconder quaisquer alterações antes que o srcdir seja atualizado / redefinido.

    

Answer 2

Parece excessivo. Pode ser possível lidar com apenas um repositório git. Tudo depende das capacidades da infraestrutura ikiwiki (sobre a qual não sei nada).

O porquê

O motivo pelo qual você deseja que o repositório seja um repositório vazio é porque um repositório não-nulo quase sempre terá uma filial com check-out. Outros repositórios git não terão permissão para entregar em uma ramificação com check-out no repositório de destino (imagine trabalhar na filial, um push acontece na sua máquina e os arquivos são modificados sob o seu nariz).

Você pode trabalhar fora do srcdir em vez de clonar o repositório. Embora isso possa causar uma contenção de recursos, se você puder modificar os arquivos ao mesmo tempo que uma edição da Web pode. Além disso, pode ficar confuso com você empurrando manualmente e ter o ikiwiki.cgi também acontecendo. O ikiwiki pode colocar ganchos que você não deseja executar em um push. Por esse motivo, suponho que eles recomendem que você clone a partir do "repositório".

Um recurso do Git

Quando você clona um repositório git de uma máquina local, o git faz otimizações significativas. Se você usar a opção --local (que é o padrão se você usar git clone /path/to/repo ), ela usará hardlinking do histórico comum que compartilham, economizando espaço em disco. Aqui está um trecho de 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.

O excesso de espaço em disco não está no diretório .git/objects , mas sim no próprio check-out. Se isso ainda for excessivo para você, talvez seja melhor continuar procurando outra solução.

Conclusão

A menos que você saiba muito sobre o funcionamento interno de ikiwiki , eu não tentaria contornar a maneira recomendada de configurá-lo. Eu consideraria inseguro. Se você quer uma resposta melhor do que isso, você pode querer ir para um fórum melhor com mais conhecimento sobre ikiwiki .

O espaço em disco extra usado é um problema menor quando você percebe que o git executa hard-linking dos arquivos internos do objeto git.