Git 1.7.7

    Здравствуйте,

    Тихо и незаметно (по крайней мере на Хабре) вышло обновления для git. Полный changelog. Кратко опишу главные вкусности, которым я очень рад и думаю вы тоже будете рады.

    git stash --include-untracked

    Или -u позволить застэшить (не знаю как лучше, еще можно «отложить на полку», «спрятать») не только те файлы, которые уже под версионным контролем, но и новые созданные файлы, которые вы еще не добавили. Тем, кто часто переключается между ветками будет полезно.

    git submodule update

    Теперь апдейт сабмодулей не будет останавливать работу, если случилась ошибка. Он таки проапдейтит все сабмодули, которые подключены, а в конце выдаст список ошибок, которые произошли (если такие имеются конечно).

    git push --recurse-submodules=check

    С такой директивой пуш не произойдет, если у ваших сабмодулей есть комиты, которые не лежат еще в публичных репозиториях. Другими словами, если вы комитили локально в сабмодуль, не пушнули его, а потом пушите супермодуль, то гит скажет «айайай, так сильно нехорошо».

    git svn

    Обновление дополнения. В ченджлоге нету деталей по этому поводу, но предположу, что git таки научился с svn вычитывать точки мерджа. Завтра буду на работе и подтвержу (см. UPD) это.

    git log --decorate

    Научился подсвечивать привитые (grafted) или замененные коммиты.

    UPD: Таки да, гит научился вычитывать ветвление с svn.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 16

      +11
      > git push --recurse-submodules=check

      мастхэв
        +1
        Подскажите пожалуйста. Можно ли как-то отучить Git коммитить файлы, которые не содержат в содержимом никаких изменений, но имеют разную дату редактирования. Сейчас у меня постоянно возникает проблема при поиске какой-нибудь ошибки. Сделал промежуточный вывод, удалил. Файл не изменился, но Git считает своим долгом его закоммитить. Получается каша.
          +2
          Гит не умеет коммитить что-либо по своему желанию. Он коммитит только то, на что вы ему укажите. Опишите, пожалуйста, подробнее, что у вас за промежуточный вывод и каким образом гит считает своим долгом его закоммитить.
            +1
            Я не очень продвинутый в этом пользователь, может что-то не так делаю. У меня небольшой проект на PHP в виде модуля к CMS. У меня есть две папки. В одной у меня полностью настроенная CMS, а во второй выделенные файлы для коммита. Так вот, я делаю сейчас такую операцию:
            — Сравниваю все файлы в двух папках и нахожу измененные файлы.
            — Копирую только измененные файлы.
            — Пишу в консоли git commit -a -m «Комментарий»
            — Пишу в консоли git push

            В таком виде это работает.

            А если я просто скопирую все файлы (а не только измененные) из одной папки в другую, то git коммитит абсолютно все скопированные файлы.
              +4
              Почитайте внимательнее о флаге -a. Если он есть, гит добавляет до стейджинга все файлы и потом комитит. Пользутейсь git add а потом commit -m. Также непонятна структура, зачем вам две отдельных папки?
                +1
                Спасибо за направление, буду разбираться.

                Две папки, так как модуль по сути разрабатывается для продакшена, а коммитится немного модифицированная версия (отличаются шаблоны, конфиги).
                  +3
                  Не совсем понятен из ответа критерий по которому коммитятся файлы, но в любом случае мне кажется в Вашем случае нужно держать второй локальный репозиторий, а не просто дублирующую папку — так много проще и отбирать файлы для комита (бонус: можно коммитить только часть файлов; см. `git add -p`), и обновлять только изменившиеся файлы (обычным пушем, ведь только нужные файлы окажутся закоммиченными в дублируюший репозиторий).
                  Если немного дополнить схему работы, можно также обеспесить версионирование файлов, которые изменяются, но сейчас не комитятся («для продакщена»).
                    +4
                    Вам нужны две ветки уже. production и develop.
                  +4
                  И да, убедитесь что у вас входящие файлы (те, которые вы стянули с репозитория) имеют EOL-style такой же, как и в настройках редактора. Может быть он заменяет EOL`и, соответсвенно файлы становятся измененными.
                    +8
                    А попробуйте иметь две ветки вместо двух папок. Может стать удобнее.

                    Соответственно
                    git checkout production
                    и
                    git checkout master
                    будут переключать между ветками, можно комиттить в одной, а потом мерджить изменения в другую.

                    Осмелюсь предложить мерджиться
                    git merge --squash master
                    в production-ветке, который не создаст коммиты на ветке production, а просто накатит все изменения скопом и будет ждать вашего решения (как это было бы с тупо изменёнными файлами).
                    То есть Вы разрабатываете в master, комиттите туда всё, потом переходите в production, и туда сквашитесь.

                    А потом там, где собственно работает сервер, просто делаете
                    git clone <…>
                    и
                    git checkout origin/production

                    Вот вы не продакшен-ветке. Потом обычным git pull обновляетесь по мере появления на ней изменений.

                    Тем самым, у вас есть возможность отслеживать изменения обеих веток в одном месте, и перекрёстно опылять их в любой момент.
                      0
                      Спасибо, но у меня по сути есть публичная версия (master), а версию production не очень-то хотелось бы публиковать. Поэтому максимум, вероятно, что можно использовать — сделать еще дополнительный локальный репозиторий.
                        0
                        Так погодите, у гита же на origin не все ветки можно заливать.
                        А как раз только избранные.
                        То есть каждый раз, когда вы делаете
                        git checkout -b new_branch
                        эта самая new_branch создаётся только локально, и по
                        git push
                        никуда без спец. ухищрений отправлена не будет.

                        Под ухищрениями я понимаю
                        git push origin new_branch
                        который собственно удалённую ветку origin/new_branch и создаст.
                          0
                          Интересная особенность! Спасибо, буду углубляться в тему :).
                      0
                      У меня TurtiiseGIT в окне комита показывает все файлы с изменившейся датой.
                      Но даже если разрешить ему их коммитить, оставив у них галочки, после этого в логе я вижу только реальные изменения.

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

                      Занятно, что у Вас такой же глюк в консоли… я думал, это интерфейсное у черепаха.
                  +18
                  «Застешить» — это хорошо, но лучше «заначить» %)
                    +3
                    заныкать, угу

                  Only users with full accounts can post comments. Log in, please.