LINUX.ORG.RU

git плохо переключает ветки

 


0

1

при переключении между ветками остаются директории, «доставшиеся» по наследству из предыдущего бранча

гит не не кажет их как новые, но и не отдает по ним историю (git log — ./strange_directory отдает пустой лист со словом END в начале). Это нормально?

репозиторий клонировал заново - сразу после свежего чекаута вроде все в порядке, но потом неизменно снова ломается. git reset --hard HEAD, интерактивный рибейз, итп - ничего не помогает

клонировал на другой жесткий диск - та же проблема.

платформа - OSX постоянно, один раз видел под линуксом, под виндой не видел никогда (с другой стороны, у меня и нет винды своей..)

ничего не понимаю :(

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)

git не умеет «хранить» пустые директории (и директории вообще). Максимум что он может - удалить пустую директорию после удаления всех файлов, про которые git был в курсе. Чини свои скрипты сборки или что там у тебя используется, чтобы они не оставляли за собой мусор.

Deleted
()

это нормальное поведение. если я правильно понимаю, то он и не должен обновлять файлы, которых нет в том бранче, на который ты переключился. первое, что пришло в голову, это

git checkout --detach <branch>
git checkout <branch>
но не особо знаю, правильно ли так делать

f1u77y ★★★★
()
Ответ на: комментарий от Deleted

тс вряд ли говорит про пустые директории

f1u77y ★★★★
()

Директории используются в самом репозитории, или создаются при сборке? Они есть в .gitignore? Что говорят git status, git status --ignored?

slovazap ★★★★★
()
Ответ на: комментарий от f1u77y

это нормальное поведение. если я правильно понимаю, то он и не должен обновлять файлы, которых нет в том бранче, на который ты переключился. первое, что пришло в голову, это

Если файлы/директории есть в том бранче ИЗ которого ты переключаешься, но нет в том НА который ты переключаешься, git обязан их удалить, разумеется.

slovazap ★★★★★
()
Ответ на: комментарий от Deleted

у меня используются руки и git в zsh консольке
если конкретней, то вначале была версия git version 2.5.4 (Apple Git-61), сейчас git version 2.6.1. Обновление не помогло. Как такое может быть - не знаю, поэтому и пришел ныть сюда..

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от slovazap

ой, чет затупил. просто настолько часто с этим встречался, что уже принимаю за нормальное поведение. правда, всё же не могу понять, как сие воспроизвести

f1u77y ★★★★
()
Ответ на: комментарий от stevejobs

А в багтрекер соходить поныть не?
Заодно бы и английский прокачал ;-)

P.S. Если дойдешь до них - скидываю сюда ссылку, почитаем.

trex6 ★★★★★
()
Ответ на: комментарий от slovazap

глазами через ls видна куча директорий, которых в этом бранче быть не должно - это слишком древний бранч

для того чтобы убрать предположение f1u77y я сделал git reset --hard HEAD и теперь весь мусор точно должен исчезнуть

git status
On branch 1.1.7
Your branch is up-to-date with 'origin/1.1.7'.
nothing to commit, working directory clean
git status --ignored
On branch 1.1.7
Your branch is up-to-date with 'origin/1.1.7'.
Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

(длинный список файлов, в которых точно нет указанных директорий)
stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от Deleted

Помогло вот что: git clean -fd

Это ПОЧТИ решение за исключением вопроса...

Какого черта гит притащил директории из соседнего бранча, сделал их untracked и теперь не показывает их даже в статусе?!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от slovazap

да, ты правильно понял проблему. Вот именно этого не происходит. Вместо удаления он делает их untracked (что бы это ни значило в данном случае).

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от aarexer

Это сорцы. Файлы проекта. В том-то и проблема, что я меняю бранч, там другой набор сырцов и другие настройки IDE Intellij Idea - и у Idea от этого срывает башню, она пытается все это попарсить (несовместимый набор исходников), ей случается плохо, и результаты приходится разбирать вручную

ну блин. ну ладно, придется каждую команду в гите теперь предварять git clean -fd и mvn clean install (чтобы перегенерить исходники, которые git clean сотрет)

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

А почему ты сделал вывод, что виновата Idea в этом? А ты чекауты между бранчами делаешь с помощью Idea или прямо в консоли?Ты писал вроде, что из консоли. А если вот взять и выключить idea, оставить только консоль и сделать чекаут из одной в другую бранч - будет же тоже самое?Тогда idea не при чем будет. Можешь проверить?

aarexer
()

Ещё один неосилятор не осилил 800 страниц стандарта.

anonymous
()

Может в этих директориях лежат файлы, которые не трекаются гитом?

andreyu ★★★★★
()

Могу ошибаться, но GIT все подчищает за собой как правило при переключении веток. Тут явно какой-то косяк, возможно с .gitignore

«Игнор» и untracked артефакты в студию

anonymous
()

Как вам правильно уже сказали выше, одна из возможных причин - натыки с .gitignore. Не факт, что он должен быть локальным. Я сталкивался пару раз с такими «файлами», куда разрабы пихали всякий хлам, который относится чисто к их локальным компам. Тем паче что вы говорите, что клонируете откуда-то. Структуру и эксклюды в студию. Никто в здравом уме не станет пихать туда свои .my_ide_environment/vim-swap'ы/что там у вас. Люди зачастую и используют глобальный файл. Самый банальный вариант - одинаковые директории в

git config --global core.excludesfile ~/.my_full_global_ex

Допустим:

самое_распространенное_имя_раз/

самое_распространенное_имя_два/

Которые могут быть почти во всех проектах. А потом вы выкачиваете проект, и, внезапно, у вас оказываются лишние неотслеживаемые файлы. И это только одна из возможных причин. Git достаточно стабилен, чтобы не нести охинею при отработке переходов. Чудес не бывает. Показывайте глобальные/локальные эксклюды + структуру проекта (никто ж не заставляет вас светить код)

znenyegvkby
()

Кстати, вот еще что (если у вас большая история, и тем более n->infinity разработчиков, эта ситуация вполне вероятна) Вот вы вчера отслеживали файл X - а сегодня решили, что больше не хотите. И тупо пытаетесь игнорить его через .gitignore. (Да да, такое вполне бывает) Так вот git и не собирается игнорировать такой файл и в этом нет ничего удивительного. После вашего базового коммита, git уже начал отслеживать файл (если вы конечно изначально не сказали ему обратного) и пусть бы вы даже с базовым коммитом послали туда .gitignore, git'у все равно было бы на это пофиг. Он ничего не хочет знать пока вы не удалите файл из буфера слежения

git remove --cache f
или просто из своей рабочей ветки
git remove f
И уже после этого не заигнорите (если выбросили из буфа, конечно)

Я понимаю, что это дет. сад git'а, но иногда вот такие вот казусы и находишь в проектах :) Так что это вполне себе куллстори :)

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

речь идет о корневых директориях проекта, названных по имени подпроекта. Это точно не распространенные имена, они специально написаны по конвенции, по которой не могут повторяться никогда.

stevejobs ★★★★☆
() автор топика

если директории не пустые (например, если в них сгенеренные файлы + .gitignore) — гит не имеет права их удалять. так что да, this:

Это нормально?

waker ★★★★★
()
Ответ на: комментарий от stevejobs

Госпаде, да причем тут это. Я же объяснил вам, что это один из возможных вариантов, и тут же, через коммент дал вам еще один вариант. Могу еще вам накидать этих самых вариантов выше крыши. Но суть одна, я же написал

Git достаточно стабилен, чтобы не нести охинею при отработке переходов. Чудес не бывает.

Чудес не бывает.

Вам сказали уже, в том числе и я - выкатывайте в студию структуру вашего проекта/экслюды/конфиги/etc

речь идет о корневых директориях проекта,

Где они? Где ваша структура? Где ваши эксклюды? Где ваши настройки? Тут что по вашему - телепаты? Если вы хотели ответа на единственный ваш вопрос

при переключении между ветками остаются директории, «доставшиеся» по наследству из предыдущего бранча

гит не не кажет их как новые, но и не отдает по ним историю (git log — ./strange_directory отдает пустой лист со словом END в начале). Это нормально?

Это нормально?

То вот вам ответ:

Да. Это - нормально! Какую вообще «историю» вы хотите от git'а, если сами пишите выше, что файлы неотслеживаемые?

Больше я не увидел ни одного вопроса - так же я не увидел от вас ни дельного объяснения, ни доп. информации (при учете, что окромя меня ее просили у вас уже как минимум 3 раза)

znenyegvkby
()
Ответ на: комментарий от stevejobs

Учись держать рабочую git дирректорию в чистом состоянии. Т.е. так чтобы git status выдавал пустой список файлов, если тебе нечего коммитить. Тогда и команда git clean будет очень удобной. Но если что-то полезное есть, это можно засунуть в stash, а после git clean восстановить из него. Вообще, как может быть что-то полезным, если ты не хочешь это коммитить?

rupert ★★★★★
()
Ответ на: комментарий от znenyegvkby

я уже объяснил структуру. Есть закоммитанная директория с файлами, которая в одном бранче (А) есть, в другом бранче (Б) - нету. При переключении с А на Б директория вместе со всем содержимым остается на файловой системе. Я утверждаю, что этого быть не должно.

чувак, стиль изложения тобой материала вызывает во мне боль. Поэтому дальше я буду игнорировать твои комментарии. Они не приносят пользы. Сорри.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Возможно.

генерация такого количества кода занимает очень много времени. Генерить каждый раз заново совершенно не вариант, нужно хранить кэш.

Вот в этом и проблема. С нуля слишком долго собирается, поэтому ты хранишь артифакты сборки. Вам надо эквивалент ccache для вашего генератора, тогда кэш сгенирированных классов будет абсолютно независим от git рабочей дирректории, и git clean можно будет делать легко и непринуждённо.

rupert ★★★★★
()
Ответ на: комментарий от rupert

это не наш генератор, это стандартный для джавы. мы используем сборку с помощью maven, оно генерит все в каталог target рядом с исходниками, туда и никуда иначе. Плагин сборки можно перенастроить на генерацию в другое место, но такое поведение не совместимо с конвенциями для мавена, от этого совершенно вся сборка рассыпется

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Есть закоммитанная директория с файлами, которая в одном бранче (А) есть, в другом бранче (Б) - нету. При переключении с А на Б директория вместе со всем содержимым остается на файловой системе. Я утверждаю, что этого быть не должно.

Оке, Стиви.

git status
On branch master
nothing to commit, working directory clean
ls -a
./  ../  .git/  dir1/
mkdir dir_test
cd dir_test/
vim test.ini
cd ../
git add --all dir_test/
git commit -m 'add dir_test -> test.ini'

Есть закоммитанная директория с файлами, которая в одном бранче (А) есть

Условие 1 выполняется.

git checkout test_branch_2
git status
On branch test_branch_2
nothing to commit, working directory clean
ls -a
./  ../  .git/  dir1/
mkdir dir_test
cd dir_test/
vim test_file
cd ../
git add --all dir_test/
git commit -m 'add dir_test -> test_file'
git rm -r --cache dir_test/
Удалили из бранча, но не сделали коммит.

в другом бранче (Б) - нету.

Оке, делаю стэш.

git stash
rm -R dir_test/
ls -a
./  ../  .git/  dir1/
Все ок. Условие 2 выполняется.
git checkout master
ls -a
./  ../  .git/ dir_test/  dir1/
git checkout test_branch_2
ls -a
./  ../  .git/ dir_test/  dir1/
Вот тебе 3-тья ситуация (стэш), при которой

При переключении с А на Б директория вместе со всем содержимым остается на файловой системе

Я утверждаю, что этого быть не должно.

Давайдосвидания.

чувак, стиль изложения тобой материала вызывает во мне боль. Поэтому дальше я буду игнорировать твои комментарии. Они не приносят пользы. Сорри.

От темы отписался, пусть тебе «Божинька памагаит», или телепаты, которые увидят что за magic_directory, которая «в одном бранче (А) есть», «в другом бранче (Б) - нету.». И плиз, не отвечай на коммент, проигнорируй как и обещал, чтобы мне не заходить лишний раз из уведомлений=) Заранее спасибо=) Удачи в решении проблемы=)

znenyegvkby
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.