Na początek krótki przykład zastosowania, a później szersze wyjaśnienie.
$ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # another_file3.txt # file.txt # file2.txt nothing added to commit but untracked files present (use "git add" to track) $ git add --intent-to-add file.txt $ git add file2.txt another_file3.txt $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: another_file3.txt # new file: file.txt # new file: file2.txt # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: file.txt #
$ git commit -m "some files" file.txt: not added yet error: Error building trees $ git add file.txt $ git commit -m "some files" [master 787021d] somefiles 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 another_file2.txt create mode 100644 file.txt create mode 100644 file2.txt
Na początek sprawdziliśmy status plików w naszym repozytorium. Polecenie git-status wykazało, że posiadamy 3 nieśledzone pliki. Następnym krokiem było dodanie tych plików do poczekalni za pomocą polecenia git-add. Jednakże wykonując to polecenie dla pliku file.txt użyto także dodatkowego przełącznika --intent-to-add.
Przełącznik ten jest lekarstwem na naszą sklerozę w sytuacjach, w których to obiecujemy sobie, że przed commitem wprowadzimy jeszcze jakieś zmiany, których to jednak nie możemy wykonać teraz.
Jeżeli przed ostatecznym commitem nie dodamy owego pliku (tym razem już bez przełącznika) do poczekalni, to przy próbie zacommitowania zmian, dostaniemy komunikat o błędzie mówiącym, że ów plik nie został jeszcze dodany (do poczekalni).
Jak to działa?
Poczekalnia przechowuje dwie rzeczy: ścieżki do plików i zawartość pliku z chwili w której dany plik został dodany. O tym, że przechowywalnia nie trzyma samych ścieżek do plików planuję napisać następny wpis ;)
polecenie git add --intent-to-add
Przy zabawach tym poleceniem zauważyłem, że git-status trochę inaczej się zachowuje dla plików, które w ogóle nie były śledzone a dodajemy je właśnie z tym przełącznikiem i trochę inaczej dla plików już wcześniej śledzonych.
Załóżmy, że od ostatniego razu modyfikowaliśmy owe pliki jeszcze raz.
$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: another_file2.txt # modified: file.txt # modified: file2.txt # no changes added to commit (use "git add" and/or "git commit -a")
Zwróćmy uwagę na to, że tym razem te trzy pliki są wymienione po komunikacie
Changed but not updated, a nie jak poprzednim razem Untracked files. Kontynuując pracę...
$ git add another_file2.txt file2.txt $ git add -N file.txt $ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: another_file2.txt # modified: file2.txt # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: file.txt #Jak widzimy tym razem file.txt jest tylko w drugiej sekcji. Nie do końca jestem pewien dlaczego się tak dzieje, nie mniej jednak, dobrze wiedzieć że taka różnica występuję. Ta wiedza pozwoli nam lepiej kontrolować swoje postępowanie i wyniki swoich działań :)
Nie do końca rozumiem na czym ma polegać to inne traktowanie. Moim zdaniem zachowuje się prawidłowo. No może poza faktem, że zmiana add zmiana commit nie przyczepi się o tą drugą zmianę. Ale w sumie nie wiem co zrobi git status. Dawno z gita nie korzystałem, muszę nadrobić zaległości. ;D
OdpowiedzUsuńPS. Daj komcie dla normalnych ludzi bez blogera i openid (to ostatnie niby mam ale nie chce działać :<)