Dois repositorys git em um diretório?

É possível ter 2 repositorys git em um diretório? Eu acho que não, mas pensei em perguntar. Basicamente, eu gostaria de verificar em meus arquivos de configuração do diretório inicial (por exemplo, .emacs) que devem ser comuns em todas as máquinas que eu trabalho, mas ter um segundo repository para arquivos locais (por exemplo .emacs.local), que contém configurações específicas da máquina. A única maneira que posso pensar em fazer isso é ter a configuração local em um subdiretório e ignorar esse subdiretório do repository git principal. Alguma outra ideia?

Se eu entendi o que você está fazendo, você pode lidar com tudo isso em um repository, usando ramificações separadas para cada máquina e uma ramificação contendo seus arquivos de configuração de diretório inicial comuns.

Inicialize o repository e confirme os arquivos comuns, talvez renomeando a ramificação MASTER como Comum. Em seguida, crie uma ramificação separada para cada máquina com a qual você trabalha e confirme os arquivos específicos da máquina nessa ramificação. Sempre que você alterar seus arquivos comuns, mescle a ramificação comum em cada uma das ramificações da máquina e pressione para as outras máquinas (escreva um script para isso se houver muitas).

Em seguida, em cada máquina, verifique a ramificação da máquina, que também includeá os arquivos de configuração comuns.

Este artigo cobre isso relativamente bem:

https://github.com/rrrene/gitscm-next/blob/master/app/views/blog/progit/2010-04-11-environment.markdown

Basicamente, se você está trabalhando a partir da linha de comando, isso é mais simples do que você pode imaginar. Suponha que você queira 2 git repos:

 .gitone .gittwo 

Você pode configurá-los assim:

 git init . mv .git .gitone git init . mv .git .gittwo 

Você pode adicionar um arquivo e enviá-lo para apenas um assim:

 git --git-dir=.gitone add test.txt git --git-dir=.gitone commit -m "Test" 

Então as opções para git vêm primeiro, depois o comando, depois as opções do comando git. Você poderia facilmente alias um comando git como:

 #!/bin/sh alias gitone='git --git-dir=.gitone' alias gittwo='git --git-dir=.gittwo' 

Então você pode se comprometer com um ou outro com um pouco menos de digitação, como gitone commit -m "blah" .

O que parece ser mais complicado é ignorar. Como o .gitignore normalmente fica na raiz do projeto, você precisaria encontrar uma maneira de mudar isso também sem trocar a raiz inteira. Ou, você poderia usar .git / info / exclude, mas todas as ignores que você executa não serão confirmadas ou enviadas – o que poderia estragar outros usuários. Outros usando qualquer repo podem empurrar um .gitignore, o que pode causar conflitos. Não está claro para mim a melhor maneira de resolver esses problemas.

Se você preferir ferramentas GUI como o TortoiseGit, também terá alguns desafios. Você pode escrever um script pequeno que renomeie .gitone ou .gittwo para .git temporariamente para que as suposições dessas ferramentas sejam atendidas.

Dê uma olhada no submódulo git .

Os submódulos permitem que os repositorys externos sejam incorporados em um subdiretório dedicado da tree de origem, sempre apontado para um commit específico.

RichiH escreveu uma ferramenta chamada vcsh que é uma ferramenta para gerenciar dotfiles usando os repositorys nus falsos do git para colocar mais de um diretório de trabalho em $ HOME. Nada a ver com csh AFAIK.

No entanto, se você tiver vários diretórios, uma alternativa para git-submodules (que são uma dor na melhor das circunstâncias e este exemplo de uso não é a melhor das circunstâncias) é gitslave que deixa o repos de escravos verificados na ponta de um branch em todos os momentos e não requer o processo de três etapas para fazer uma alteração no repository subsidiário (checkout na ramificação correta, efetue & confirme a alteração, vá para o superprojeto e confirme o novo submódulo commit).

É possível usar a variável GIT_DIR mas tem muitas ressalvas, se você não sabe o que está fazendo.

Sim, submodules são provavelmente o que você quer. Outra opção seria ter sua cópia de trabalho em um subdiretório e, em seguida, apontar links simbólicos de seu diretório inicial para os arquivos de interesse.

Meu método preferido é usar um repository em um subdiretório e usar links simbólicos recursivos:

 git clone repo1 cd somerepo git clone repo2 cd repo2 ./build 

onde o arquivorepo / build ‘ se parece:

 #!/bin/bash SELF_PATH="$(dirname "$(readlink -f "$0")" )" # get current dir cd .. && git stash && git clean -f -d '' # remove previous symlinks cp -sR "$SELF_PATH"/* ../. # create recursive symlinks in root 

cuidado : não use ‘git add.’

A outra opção é para eles em pastas separadas e criar links físicos simbólicos de uma pasta para outra.

Por exemplo, se houver repositorys:

  1. Repo1 / FolderA
  2. Repo1 / FolderB

E:

  1. Repo2 / FolderC

Você pode FolderA FolderB as pastas FolderA e FolderB do Repo1 para o Repo2. Para as janelas, o comando para executar no Repo1 seria:

 User@Repo1$ mklink /J FullPath/Repo2/FolderA FullPath/Repo1/FolderA User@Repo1$ mklink /J FullPath/Repo2/FolderB FullPath/Repo1/FolderB User@Repo1$ printf "/FolderA/*\n/FolderB/*\n" >> .gitignore 

Para os arquivos nos repositorys principais, você precisaria criar links simbólicos para cada um deles, também adicionando-os ao repository .gitignore para evitar ruídos, a menos que você queira.

Isenção de responsabilidade: isso não é publicidade. Eu sou o desenvolvedor da biblioteca fornecida.

Eu criei uma extensão git para lidar com casos em que você deseja misturar vários repositorys em uma pasta. A vantagem da lib é manter o controle dos repositorys e conflitos de arquivos. você pode encontrá-lo no github . Existem também dois exemplos de repositorys para experimentá-lo.