Monitorar Diretório de máquina local

Olá Gabriel,

para clonar um repositório de outro diretório local, você pode fazer o comando

git clone --local file:///C:/codigos

Tentei fazer desta forma citada mas não funcionou. Vou descrever a sequência que fiz.

1 . no diretório c:\codigos usei o comando git init

2.  este diretório já tem vários arquivos de um projeto php

3. no diretório d:\ usei o git clone --local c:\codigos , mas o conteúdo de  c:\codigos não foi copiado para o d:\

O que está errado ?

Mas ele chegou a dar alguma mensagem de erro quando você fez o clone?

Não deu mensagem de erro, mas os arquivos do drive C não foram copiados para o drive D.

Será que eu entendi o processo errado?

O drive C é o remoto....e o drive D o local.

Quero trabalhar com os arquivos no drive D e depois enviá-los via GIT para o drive C.

No caso o seu drive C vai servir apenas de repositório central então. O que você pode fazer neste caso é criar dar o init no drive C com este comando aqui:

git init --bare

Ai o repositório criado servirá para compartilhamento.

Quando você fala que o C está remoto, ele está em outra máquina? Neste caso o clone deveria ser assim na verdade:

git clone git+ssh://username@192.168.1.2/~/caminho/do/arquivo

No caso o 192.168.1.2 seria o ip desta máquina.

Entendi, Lucas.

Chamei o C de "remoto" só para diferenciar o repositório onde ficarão os arquivos que posteriormente serão transferidos para o servidor web.

Mas o C é da mesma máquina.

Usei esta sequência

c:\Softwares\xampp\htdocs\cdep-2017 (master)
λ git init --bare

D:\Softwares\xampp\htdocs
λ git clone c:\Softwares\xampp\htdocs\cdep-2017

Cloning into 'cdep-2017'...

warning: You appear to have cloned an empty repository.
done.

Após fazer isto o diretório cdep-2017 foi criado no D e a pasta .git dentro do diretório. Mas, os arquivos não foram copiados.

É que o repositório em si está vazio para o git. Sem um commit ele não sabe quais arquivos gerenciar, por isso que no clone os arquivos não vieram.

E agora como ele é um repositório --bare, ele serve como um repositório central. Então se você criar algo no drive D, fizer um commit, depois der um push para enviar ai sim você verá que o arquivo passa a ser gerenciado pelo git. Inclusive se o drive D fizer o commit e push, se outro drive fizer o clone pegará especificamente esses commits enviados anteriormente.

Lucas, o que não entendi ainda é como faço os arquivos do drive C: serem copiados para o drive D: com o comando git.

Eu preciso usar o "git add ." e o "commit" no drive C: e depois usar o "git clone" no drive D: para que os arquivos seja copiados? É isto ?

Ou tenho que fazer a cópia manual do C: para o D: e só após este processo posso iniciar as operações com o git?

Fiz a sequência abaixo:

no drive C:
git init --bare
git add .
git status
git commit -m 'Primeiro Commit'

Após o git commit apareceu a mensagem de erro:

error: pathspec 'Commit'' did not match any file(s) known to git.

Por causa do erro não pude prosseguir para fazer o git clone.

Não consigo ver o que está errado.

Se você quiser dar uma commit direto no C ai no init você não pode dar o --bare, porque isso faz o repositório ser apenas de centralização. Seria parecido com um repositório no github, que a gente envia coisas para lá e ele só serve de centralizador.

Se o primeiro commit você precisa fazer diretamente no C, ai você precisa tirar o --bare, fazer só um git init e depois o commit.

Lucas, como sou leigo neste assunto GIT não estou conseguindo me explicar corretamente.

Quero fazer esta sequência:

1 tornar a pasta c:\codigos o local de centralização (ou remoto) 
2 usar o git init --bare
3 usar o git add *.*
4 acessar a pasta d:\codigos
5 usar o git clone  c:\codigos para copiar os arquivos de C: para D: (esta parte está criando a pasta mas não está trazendo os arquivos)

Fiquei congelado no passo 5. Não consigo ir adiante porque o passo cinco não traz os arquivos do C: para o D:

Já utilizei git pull e também não deu certo.

O git só versiona o arquivo quando existe um commit, não adianta só o add. E para conseguir dar o commit direto no drive C não pode se usar o bare. Então os passos que você tem que fazer são no diretório C são:

git init
git add .
git ci -m "Commit inicial"

Ai sim, quando você clonar no diretório D deveria aparecer os arquivos que estão em C.

Lucas,

Realmente não funcionou. Os arquivos não são copiados do C: para o D:

Estou fazendo testes no WINDOWS.

Farei novamente a sequencia no UBUNTU para verificar se funciona.

Mas ele chega a acusar alguma mensagem de erro em algum momento? E quando vc faz git log tanto no C quanto no D o que aparece?

Tenta esta sequencia de comandos e veja se aparece alguma mensagem de erro.

No drive C:/codigos

git init
git add .
git commit -m "Primeiro commit"

No drive D:/

git clone --local C:/codigos

Neste momento deveria aparecer uma pasta códigos em D:/

Eu fiz a sequência. A pasta aparece em D:. Não aparece nenhuma mensagem de erro. Mas, os arquivos de C não são copiados para D.

O que devo fazer agora? Usar o pull para puxar os arquivos? Indicar que o C é o diretório remoto?

Foi com estas dúvidas que travei.

Tem um erro que ocorre após o git add .

λ git add .
fatal: Unable to create 'c:/Softwares/xampp/htdocs/cdep-2017/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

Ele deu ruim na execução dos comandos, pela mensagem parece que ele nao terminou de fazer algum comando. Antes de dar o comando git init, chegou a apagar a pasta .git dentro de C:/codigos? Se não, primeiro apague a pasta .git ai sim rode a sequencia de comandos que cria o repositorio em C:/codigos

git init
git add .
git commit -m "Primeiro commit"

Lucas, vou fazer a reinstalação do GIT. Parece que tem algum problema. Para cada comando GIT que utilizo no prompt é criado um novo processo no WINDOWS. Estou com quase 20 git.exe em execução. Isto é normal?

Não deveria ter tantos processos assim... parece que eles não estão terminando. Pode ser que parando os processos e reinstalando ajude.