2015-08-04 14 views
11

Uważam, że pracując z submodułami git, często napotykam problemy z łączeniem się między zatwierdzeniami, które zawierają dane submoduły, a tymi, które reprezentują ten sam kod co normalny katalog. Mały przykład odtwarzające:Scalanie po katalogu zostało przekształcone w submodule

# Create one project, to be used as a subproject later on 
git init a 
cd a 
echo aaa > aa 
git add -A 
git commit -m a1 
cd .. 

# Create a second project, containing a as a normal directory initially 
git init b 
cd b 
mkdir a b 
echo aaa > a/aa 
echo bbb > b/bb 
git add -A 
git commit -m b1 

# Replace directory with submodule 
git rm -r a 
git submodule add ../a a 
git commit -m b2 

# Try to create branch from the pre-submodule state of affairs 
git checkout -b branch HEAD^ 

To już daje błąd:

error: The following untracked working tree files would be overwritten by checkout: 
    a/aa 
Please move or remove them before you can switch branches. 
Aborting 

W celu uniknięcia błędu, ja deinitialize wszystkie Submoduły pierwsze:

# Create feature brach starting at version without submodule 
git submodule deinit . 
git checkout -b branch HEAD^ 
echo abc > b/bb 
git commit -a -m b3 

Jak widać, gałąź funkcji jest całkowicie niezwiązana z modułem częściowym, modyfikując inny zestaw plików. Co sprawia, że ​​ten problem jest szczególnie irytujący.

# Try to merge the feature branch 
git checkout master 
git merge branch 

To nie kolejny komunikat o błędzie nie w pełni zrozumieć:

CONFLICT (file/directory): There is a directory with name a in branch. Adding a as a~HEAD 
Automatic merge failed; fix conflicts and then commit the result. 

uzyskać ten sam błąd, jeśli zrobię git submodule update --init przed git merge branch. Nie widzę każdy a~HEAD nigdzie, ani w moim drzewie katalogów ani w wyjściu z git status, który brzmi tak:

On branch master 
You have unmerged paths. 
    (fix conflicts and run "git commit") 

Changes to be committed: 

    modified: b/bb 

Unmerged paths: 
    (use "git add <file>..." to mark resolution) 

    added by us:  a 

Jeśli robię git add a jak sugeruje, otrzymuję inny błąd:

error: unable to index file a 
fatal: updating files failed 

Jeśli wykonam git submodules update --init tuż przed scaleniem, mogę pomyślnie wykonać git add a. Ale jeśli zapomnę, aby to zrobić, a następnie spróbować zrobić, że po scaleniu, że ten komunikat o błędzie:

Submodule 'a' (…/a) registered for path 'a' 
Skipping unmerged submodule a 

Jak mogę wyjść z tej sytuacji? Coś innego niż git merge --abort, ponieważ chciałbym go używać również do rzeczy takich jak git rebase, a ponieważ w niektórych sytuacjach (nie wiem, jak rozmnażać) nie mogłem nawet przerwać scalania w czysty sposób i musiałem zrobić zamiast tego twardy reset.

Jak mogę tego uniknąć? Czy jest jakieś magiczne ustawienie, które sprawia, że ​​git robi to, co właściwe, z submodułami w porównaniu do katalogów podczas scalania, więc nie muszę ręcznie przetwarzać scalania, które modyfikuje tylko pliki niezwiązane z submodułami?

+0

FYI Flaga '--abort' działa również dla rebase. – approxiblue

+0

@ user880772: Tak, ale przerywa cały zbiór, co oznacza, że ​​znaczny wysiłek może zostać utracony, jeśli po drodze pojawią się jakieś konflikty. – MvG

+1

Git [nie obsługuje łączenia modułów] (https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/). Nie na swój zwykły magiczny sposób. Jeśli nie chcesz zapomnieć o uruchomieniu aktualizacji modułu przed scaleniem, możesz zamienić "scalenie" w alias (czuję, że to okropnie sugeruję). Nie widzę tego w porządku. – approxiblue

Odpowiedz

2

Nie powinieneś dodawać, scalanie nie powinno go zmieniać. Co należy uruchomić to

git reset a 

Więc zignorować W "chage" za a.

PS: podobno git tylko sprawdza existense z katalogu, więc jeśli

git submodule deinit a 
rmdir a 

przed scalanie, będzie to sukces. Nie jestem pewien, czy tego właśnie chcesz.

0

Mam podobny problem, gdy scalam kod zawierający folder, który należy przekonwertować na moduł.

I rozwiązać go za pomocą BFG --delete-folders usunąć folder z nowym kodem źródłowym, a git gc oczyścić repozytorium, wtedy mam git rebase bez żadnych konfliktów.

Powiązane problemy