git mv i zmieniaj tylko wielkość liter katalogu

Podczas gdy znalazłem podobne pytanie , nie znalazłem odpowiedzi na mój problem

Kiedy próbuję zmienić nazwę katalogu z FOO na foo przez git mv FOO foo, dostaję

fatal: renaming 'FOO' failed: Invalid argument

DOBRZE. Więc próbujęgit mv FOO foo2 && git mv foo2 foo

Ale kiedy próbuję dokonać transakcji za pośrednictwem git commit ., dostaję

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# foo
nothing added to commit but untracked files present (use "git add" to track)

Gdy dodam katalog przez git add foonic, nic się nie zmieni i ponownie git commit .otrzymam ten sam komunikat.

Co ja robię źle? Myślałem, że używam systemu z rozróżnianiem wielkości liter (OSX), dlaczego nie mogę po prostu zmienić nazwy katalogu?

Jesteś w środowisku niewrażliwym na wielkość liter. Co więcej, dodając bez, -Anie zajmie się usunięciem strony, mvponieważ Git to rozumie. Ostrzeżenie! Upewnij się, że nie ma w pobliżu żadnych innych zmian ani nieśledzonych plików, ponieważ zostaną one zatwierdzone w ramach tej zmiany! git stash -unajpierw zrób to, a potem git stash pop. Kontynuacja: Aby obejść ten problem, wykonaj następujące czynności:

mv foo foo2
git add -A
git commit -m "renaming"
mv foo2 FOO
git add -A
git commit --amend -m "renamed foo to FOO"

Jest to wyciągnięty sposób na zmianę katalogu roboczego, zatwierdzanie, a następnie zwijanie 2 zatwierdzeń. Możesz po prostu przenieść plik do indeksu, ale dla kogoś, kto jest nowy w git, może nie być wystarczająco wyraźne, co się dzieje. Krótsza wersja to

git mv foo foo2
git mv foo2 FOO
git commit -m "changed case of dir"

Jak zasugerowano w jednym z komentarzy, możesz również zrobić interaktywny rebase ( git rebase -i HEAD~5jeśli wprowadzono niewłaściwy przypadek 5 zatwierdzeń temu), aby go naprawić i nie wyświetlać niewłaściwego przypadku w dowolnym miejscu w historii. Musisz być ostrożny, jeśli to zrobisz, ponieważ odtąd skróty zatwierdzania będą inne, a inni będą musieli bazować lub ponownie łączyć swoją pracę z niedawną przeszłością oddziału.

Jest to związane z poprawieniem nazwy pliku: czy w git nie jest rozróżniana wielkość liter?

Chcesz ustawić opcję core.ignorecasena false, co spowoduje, że Git zwróci uwagę na wielkość liter w systemach plików, które nie obsługują go natywnie. Aby włączyć w repozytorium:

$ git config core.ignorecase false

Następnie możesz zmienić nazwę pliku za pomocą git mvi będzie działać zgodnie z oczekiwaniami.

Udało mi się to rozwiązać, używając git 1.7.7, używając tymczasowej nazwy pliku:

$ git mv improper_Case improve_case2
$ git mv improve_case2 improve_case
$ git commit -m "<your message>"

(git mv -bezpłatny wariant.)

Ten problem napotkałem w Git na Mac OS X 10.9. Rozwiązałem to w następujący sposób:

git rm -r --cached /path/to/directory

To ustawia katalog do usunięcia w Git, ale tak naprawdę nie usuwa żadnych fizycznych plików (--cached ). To sprawia, że ​​katalog, teraz z odpowiednią literą, pojawia się w nieśledzonych plikach.

Możesz to zrobić:

mv /path/to/directory /path/to/DIRECTORY
git add -A /path/to/DIRECTORY

Git rozpozna wtedy, że zmieniłeś nazwy plików, a kiedy to zrobisz git status, powinieneś zobaczyć kilka renamed:linii. Sprawdź je i upewnij się, że wyglądają poprawnie, a jeśli tak, możesz zatwierdzić zmiany normalnie.

Jest to szybkie i bezpieczne rozwiązanie:

git mv -f path/to/foo/* path/to/FOO/

Ostrzeżenie! Zawsze zmieniaj nazwy wszystkich plików w folderze o zmienionej nazwie (użyj /*).

Nie zmieniaj nazw pojedynczych plików. Prowadzi to do błędu opisanego w tej odpowiedzi .

Jeśli chcesz najpierw zobaczyć wynik, użyj -n:

git mv -f -n path/to/foo/* path/to/FOO/

Po dokonaniu mv:

1. Zatwierdź zmiany
2. Kasa do dowolnej innej wersji
3. Kasa z powrotem.

Teraz Git powinien zmienić nazwę folderu ZARÓWNO w swoich plikach wewnętrznych i systemie plików.

Wymuś to z opcją -f:

git mv -f FOO foo

Miałem jeden związany problem.

Jeden folder o nazwie „Pro” (utworzony jako pierwszy) i inny „pro” (utworzony przez pomyłkę). Na Macu jest to to samo, ale różni się w zależności od git.

$ git config core.ignorecase false

git config zmienia nazwy plików na właściwy folder (dzięki), a także tworzy pliki duchów w 'pro' (Nie !!). Nie mogłem dodać zmian pliku widma do ścieżki i nie mogłem wyewidencjonować innych gałęzi, chyba że niosę te pliki ze sobą, a także nie mogłem go zresetować.

Zamiast tego zrobiłem

$ git rm -r --cached pro
$ git status // => pro files removed, new Pro files untracked
$ git add Pro

Aby uczynić go wyjątkowo bezpiecznym, zrobiłem to w oddzielnej gałęzi napraw, a następnie ponownie połączyłem się z główną gałęzią

Czy dla guru utworzonego przez plik ducha każdy guru może wyjaśnić, jak i dlaczego? Z góry dziękuję.

Nie używasz systemu plików z rozróżnianiem wielkości liter w OS X, chyba że wyraźnie wybierzesz taki system. HFS + może być wielkość liter, ale domyślnie jest wielkość liter.

Oto naprawdę proste rozwiązanie dotyczące całego gitfoo na tej stronie.

1. Skopiuj pliki z projektu ręcznie.
2. git rm wszystkie pliki.
3. git commit jak zwykle.
4. dodaj pliki z powrotem ręcznie.
5. git dodaj wszystkie pliki.
6. git commit jak zwykle.
7. zysk.

Poprawienie odpowiedzi Adama Dymitruka (głupie, że SO nie pozwala mi skomentować jego odpowiedzi), użycie „git mv” automatycznie ustawi dokładnie przeniesione pliki. Nie jest konieczne składowanie i ryzykownego „git add -A” można uniknąć:

old="abc";    new="ABC";
tmp="$old-renamed";
git mv "$old" "$tmp";
git commit -m "Renamed '$old' to '$tmp'.";
git mv "$tmp" "$new";
git commit --amend -m "Renamed '$old' to '$new'.";

Działa to świetnie dla mnie w systemie Windows. Używany PowerShell z następującymi elementami:

1. mv .\Folder-With-Wrong-Casing .\temp
2. git add -A
3. git commit -m "renamed folder with wrong casing to temp"
4. mv .\temp .\Folder-with-Correct-Casing
5. git add -A
6. git commit --amend -m "Renamed to proper casing"
7. (opcjonalny) git push

Dzięki powyższej odpowiedzi Adama.