И совсем уж забыл — 4. Как из удаленного репозитория R скопировать обновления в не очень удаленный репозиторий L без того, чтобы убить в L все то, что вы там наработали на настоящий момент. Очень полезно, когда например вы работаете автономно.
Автор, если уж затрагиваем продвинутые темы, то пожалуйста (! пожалуйста !) опишите следующие операции:
1. Скопировать (но не rebase) изменения с ветки А на ветку Б. При нормальной работе в команде разработчиков rebase просто делать нельзя, он уничтожает по умолчанию исходную ветку.
2. Как найти общий коммит для двух веток.
3. Как найти какой коммит УДАЛИЛ конкретную строку из старой версии. Ну и заодно — рассказать про git blame.
Вот-вот, у меня вопрос — а почему просто не проиграть что-то уникальное на одном устройстве и найти это на других?
По крайней мере это будет вызывать меньше параноидальных подозрений… не люблю, когда на моем телефоне вдруг зажигается иконка доступа к звуку-видео просто так.
Требования на гугл распространяются потому, что он ведет бизнес в России и собирает (обрабатывает) данные российских пользователей. Требования ЕС на российских операторов не распространяются если эти операторы не ведут бизнес в ЕС и не собирают (обрабатывают) данные граждан ЕС.
Работа такая. Нужен результат, а он помимо моего, включает в частности и выполнение огромного и чужого кода, который считается написаным и работающим. Но он не работает… иногда, лезешь в него, а там… Становиться специалистом по этому коду и назубок знать, что там перезагружено и какие классы для чего — менять профиль, а рез-т все-таки нужен, и ясно, что где-то элементарная описка. Но где?
О! Документированые перезагрузки. Извините, не встречал, ни разу. Комментарии около текста, где определяется перезагрузка еще могут быть, но их еще найти надо в коде на тысячи строк и сотен файлов. А чтобы искать, надо ЗНАТЬ, что они есть и какие есть, между прочим.
Самая большая проблема здесь — навязывание мнения: OK, Google, какая лопата лучше всего?
Если ты спросишь у соседа, то мнение соседа слева будет отличаться от мнения соседа справа. А Гугл выдаст тебе то, что он выдаст еще паре миллионов людей.
Просто достало, извините. Никто из больших адептов C++ перезагрузки операторов не хочет заниматься сопровождением и отладкой больших чужих C++ комплексов.
Да. Бесконтрольное использование этого ведет к проблемам, и я не слышал о серьезных попытках их ограничить или облегчить анализ-отладку. Я работал только с одним случаем, когда это все сильно помогло и делало программу достаточно компактной — C++ парсер для ASN1 сообщения, который (парсер) генерировался. Правда код совершенно нечитаемый получался, и ходят слухи, что один из авторов жаловался, что компиляторы с Algol68 не очень распространены, код для Algol68 сгенерить можно было бы еще проще.
Извините, но это несерьезный аргумент в пользу overloading. Он может работать на небольшой программе, но в случае комплексов на сотни тысяч строк кода поиск ошибок слишком дорого обходится.
Скажите, если не секрет — вам приходилось адаптировать под новую платформу некую, систему на C++ размером в двоичном коде от 10MB до 16MB кода и числом строчек исходного кода за 200000?
Мне пришлось, и она тупо падала неизвестно где и откуда. Я потратил дня 3-4 прежде чем понял, что результат присвоения не гарантирован. Инструкцию к языку я конечно прочел годы назад. Но не был готов, что на C++ надо проверять каждый шаг и если упустил перезагрузку оператора в 200тыс строк кода для этого типа данных, то увы…
> С++ это уже все же «швейцарский нож». Все удобнее, все быстрее пишется, зачастую код еще оказывается более переносимый, есть готовые модули, но плата за это производительность.
а также проблемы при сопровождении, если программа превышает некий предел размера (порядка 5000-10000 строк). Из-за неустойчивости кода — ты никогда не знаешь, действительно ли оператор присвоения это просто оператор присвоения. Ты также никогда не знаешь, какой метод будет реально вызван из этого места поскольку у тебя с десяток классов, наследующих один и тот же класс и имеющих одинаковое имя.
А уж насчет сопровождения и отладки чужих C++, это вообще полный восторг. Попытки угадать, какой метод, из какого класса будет вызван сегодня из этой функции обречены на неудачу (если ты не писал сам это приложение).
Если написано func1(), то простой поиск по большинству C++ приложений показывает как минимум 2-3 функции с таким именем, и даже число и тип параметров совпадает — inheritance, sir!
1. Скопировать (но не rebase) изменения с ветки А на ветку Б. При нормальной работе в команде разработчиков rebase просто делать нельзя, он уничтожает по умолчанию исходную ветку.
2. Как найти общий коммит для двух веток.
3. Как найти какой коммит УДАЛИЛ конкретную строку из старой версии. Ну и заодно — рассказать про git blame.
К сожалению, сейчас уже мало кто читает книги…
По крайней мере это будет вызывать меньше параноидальных подозрений… не люблю, когда на моем телефоне вдруг зажигается иконка доступа к звуку-видео просто так.
Если ты спросишь у соседа, то мнение соседа слева будет отличаться от мнения соседа справа. А Гугл выдаст тебе то, что он выдаст еще паре миллионов людей.
Мне пришлось, и она тупо падала неизвестно где и откуда. Я потратил дня 3-4 прежде чем понял, что результат присвоения не гарантирован. Инструкцию к языку я конечно прочел годы назад. Но не был готов, что на C++ надо проверять каждый шаг и если упустил перезагрузку оператора в 200тыс строк кода для этого типа данных, то увы…
а также проблемы при сопровождении, если программа превышает некий предел размера (порядка 5000-10000 строк). Из-за неустойчивости кода — ты никогда не знаешь, действительно ли оператор присвоения это просто оператор присвоения. Ты также никогда не знаешь, какой метод будет реально вызван из этого места поскольку у тебя с десяток классов, наследующих один и тот же класс и имеющих одинаковое имя.
Если написано func1(), то простой поиск по большинству C++ приложений показывает как минимум 2-3 функции с таким именем, и даже число и тип параметров совпадает — inheritance, sir!
…
myprint(a);
b = a;
myprint(b);
…
0x00143020
0x00285040
…
Я был в полном… «восторге»! Operation overload!