The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск распределенной системы управления исходными текстами Git 2.5.0

28.07.2015 16:03

Представлен релиз распределенной системы управления исходными текстами Git 2.5.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Android, LibreOffice, Systemd, X.Org, Wayland, Mesa, Gstreamer, Wine, Debian, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL, VideoLAN, PHP, Xen, Minix.

По сравнению с прошлым выпуском в новую версию принято 583 изменения, подготовленные при участии 70 разработчиков, из которых 21 впервые приняли своё участие в разработке. В новом выпуске представлены в основном исправления ошибок и мелкие улучшения, значительные изменения отсутствуют. Основные изменения:

  • Новое сокращение branch@{push}, обозначающее удалённую отслеживаемую ветку, в которую будут помещены push-операции;
  • В команду "git send-email" добавлена поддержка файла /etc/aliases, используемого в sendmail;
  • В низкоуровневые внешние драйверы обеспечения слияния данных от трёх источников, помимо имён трёх временных файлов (%O, %A и %B) теперь передаётся финальный путь (%P);
  • Улучшена эвристика определения ошибок в определении путей в параметрах командной строки, что сняло ограничение на разделение опцией "--" похожих на имена файлов параметров в "git grep" (вместо "git grep строка -- *.c" теперь можно указывать "git grep строка *.c");
  • В скриптах с фильтрами обеспечена возможность завершения работы с выводом ошибки до того, как будут получены все данные от Git (при записи игнорируется EPIPE);
  • В "git diff" добавлена опция "--ws-error-highlight", подсвечивающая завершающие строку символы пробелов при отображении изменений;
  • Команда "git merge FETCH_HEAD" теперь учитывает, что ранее выполненный запрос "git fetch" может привести к множественному слиянию (Octopus merge) и избавляет от необходимости использования синтаксиса "git merge msg HEAD commits" в скриптах git pull;
  • В "git cat-file --batch" добавлена опция "--follow-symlinks", допускающая обход символических ссылок при запросе объекта по хэшу SHA-1. Например, HEAD:RelNotes может быть ссылкой на Documentation/RelNotes/2.5.0.txt и при указании данной опции git будет считать, что на входе Documentation/RelNotes/2.5.0.txt вместо HEAD:RelNotes;
  • Представлена замена для скрипта contrib/workdir/git-new-workdir, не зависящая от символических ссылок и надёжно обеспечивающая совместное использование объектов и ссылок.


  1. Главная ссылка к новости (https://lkml.org/lkml/2015/7/2...)
  2. OpenNews: Представлен dgit 1.0, инструмент для работы с архивом Debian в стиле Git
  3. OpenNews: В Launchpad появилась экспериментальная поддержка Git
  4. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.4.0
  5. OpenNews: GitHub представил Git-хранилище для больших файлов
  6. OpenNews: Git исполнилось 10 лет
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42679-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (74) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 16:36, 28/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –33 +/
    Хоть бы слово про "упростили", а то все это консольное вырвиглазие просто невозможно использовать без слез. 80% хватило бы 20% функционала, только если бы доступ к нему был человеческий, а не через заднее место.

    Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд. Охрененно удобная система!

     
     
  • 2.3, Аноним (-), 16:53, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Прочитай уже Pro Git, наконец.
     
     
  • 3.30, Аноним (-), 00:45, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тем более, что Pro Git выложена на официальном сайте git, и даже переведена там на русский язык https://git-scm.com/book/ru/v1
     
  • 2.4, anonymous (??), 16:55, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.

    Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf .git, все остальное легко откатывается

     
     
  • 3.6, rshadow (ok), 17:03, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    ... если знаешь магические слова
     
  • 3.7, rshadow (ok), 17:06, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И да, на репозиторий насрать (его можно восстановить из другого), главное чтобы исходники не пострадали. А вот откатить случайное действие без перечитывания "Pro Git" реально под силу немногим.
     
  • 3.9, Аноним (-), 17:15, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.
    > Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf
    > .git, все остальное легко откатывается

    откати мне rebase

     
     
  • 4.10, waker (ok), 17:20, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > откати мне rebase

    man git-reflog

     
     
  • 5.12, rshadow (ok), 17:26, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    DBA сертификаты по Git уже кто-то выдает или еще нет?
     
     
  • 6.18, fail (?), 18:36, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > DBA сертификаты по Git уже кто-то выдает или еще нет?

    угу, Git certified CCNA

     
     
  • 7.28, Аноним (-), 23:22, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    CCNA - это дети в сетях.
     
  • 4.11, Коля (?), 17:24, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    man git-show-ref
     
  • 4.17, Andrey Mitrofanov (?), 18:33, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> .git, все остальное легко откатывается
    > откати мне rebase

    Сам себе duckduckgo.com/?q=rebase+undo откати.

     
  • 3.39, Michael Shigorin (ok), 12:30, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.
    > Надеюсь, что один

    Ну я порой бэкаплю перед сложными git rebase -i, чтоб не раскапывать потом git reflog.

    PS: http://tomayko.com/writings/the-thing-about-git

     
     
  • 4.45, tamerlan311 (?), 14:30, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А временную ветку создать перед ребейзом религия не позволяет?
     
     
  • 5.47, arisu (ok), 14:56, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А временную ветку создать перед ребейзом религия не позволяет?

    до этого места ещё не дочитал, угу.

     
  • 3.82, Аноним (-), 19:47, 03/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    еще git clean -fdx нельзя откатить, пару раз так терял нужные файлики хоть и не сильно критичные
     
  • 2.13, derfenix (ok), 17:33, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Джавы с джаваскриптом вам мало, так теперь ещё и джит? Болезнь-то прогрессирует...
     
     
  • 3.41, Джо (?), 12:34, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Выпей гин с тоником
     
     
  • 4.42, derfenix (ok), 12:40, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Выпей гин с тоником

    ох лол.. Ок, сразу после того, как ты найдёшь в джугле, где его купить подешевле.
    Ещё давай позовём джида (вместо гида), снимем пару джёрлс в сауну в джималаях и запишем джигабайты хоум-видео на эту тему. Мне продолжать?

     
     
  • 5.43, burjui (ok), 13:57, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне продолжать?

    Напиши стихотворение и выложи на джитхуб.

     
  • 5.69, Джо (?), 12:56, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    gin, giraffe, giant, ginger - читается как "дж". Недавно узнал в комментах про произношение gif.

    Но это скорее ради хохмы ради, git официально считается гит http://english.stackexchange.com/questions/47622/how-do-you-pronounce-git как презентовал сам Линас Торвальдс

     
  • 2.14, Пользователь Debian (?), 17:36, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, один.
     
  • 2.15, Andrey Mitrofanov (?), 18:29, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хоть бы слово про "упростили",

    Уже давно https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html , документацию же читать надо.

     
     
  • 3.70, snoopvcs (?), 17:18, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Smoke git everyday
     
  • 2.19, Аноним (-), 18:52, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так почитайте документацию по git. Там хорошо описаны многие моменты.
    https://git-scm.com/book/ru/v1/Введение
    Советую с самой первой главы.
    А далее, чтобы упростить жизнь можете создавать скрипты. Например, можно сделать скрипт для создания ветки для новой версии, где будет происходить сразу
    git checkout -b project-v1.x.x
    и
    git tag -a v1.x.x -m 'Версия 1.x.x'.

    Одинаковые аргументы, думаю, заметны. ;) К тому же скрипты уменьшат шансы ошибки из-за человеческого фактора.

     
  • 2.22, Stax (ok), 20:14, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд. Охрененно удобная система!

    Если честно, я это делаю и в hg, и в svn. В svn вообще жесть после неудачного большого мержа, частично выполненного, частично провалившегося. Подозреваю, что какими-то хитрыми командами во всех VCS можно откатить даже сложные команды, но сделать копию тупо проще, чем их искать...

     
  • 2.34, Аноним (-), 05:52, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.

    Естественно не один, дураков вокруг достаточно. Кто папок с мамками бэкапит, кто даже название утилиты прочитать не может, куда там две строчки документации прочитать.

    > Охрененно удобная система!

    Метлу вам в руки. Там ничего бэкапить не надо.

     
     
  • 3.40, Michael Shigorin (ok), 12:33, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Метлу вам в руки. Там ничего бэкапить не надо.

    Как, а саму метлу?

     
  • 2.36, mine (ok), 10:01, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вас таких 95%. Правда остальные даже не знают, что такое Git и зачем он нужен. Они вообще в программирование не лезут.
     
  • 2.37, Аноним (-), 10:34, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Специально для вас: http://www.youtube.com/watch?v=hkBVAi3oKvo
     
  • 2.52, diderevyagin (?), 17:04, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > делает бекапы папки с джит перед выполнением сложных команд.

    Прочитайте наконец документацию по Git.
    Может это поможет Вам не писать х..и и тратить рабочее время на бредовые вещи.  

     

  • 1.5, Ури (?), 16:57, 28/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Не удобная, а универсальная.

    Для удобств есть gitk, gitg, smartgit (для нон коммершиал - бесплатный), и вообще https://git-scm.com/download/gui/linux

     
  • 1.16, ЯвныйОлкоголек (?), 18:32, 28/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    TortoiseGit под винду и оверхеад как рукой сняло!
    Возможно, самый лучший гип для git *fix*
     
     
  • 2.20, Ivan1986 (?), 19:27, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ой, только не это, оно через такую попу работает, как и все в винде
     
     
  • 3.21, программист (?), 19:39, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы ещё под Винду актуальные версии Git были. А так на 1.9.5 сидим.
     
     
  • 4.27, Аноним (-), 23:05, 28/07/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну хоть одна хорошая новость за сегодня!
     
     
  • 5.29, Аноним (-), 00:18, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну хоть одна хорошая новость за сегодня!

    Ну, да... Как это здорово... Хоть у кого-то хуже чем у тебя

     
     
  • 6.38, Аноним (-), 10:49, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Кто-то пользуется виндой и страдает за свои убеждения!
     
     
  • 7.44, программист (?), 13:58, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы пользовался и Linux, если бы была нормальная альтернатива Office и прежде всего Outlook. На прошлой работе сидел на Mint c Виндой в VirtualBox. Сейчас просто на Винде.
     
     
  • 8.49, Andrey Mitrofanov (?), 15:03, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чего только люди не учудят, чтобы не пользоваться Имаксом I I ... текст свёрнут, показать
     
     
  • 9.72, программист (?), 17:36, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А Имакс тут каким боком ... текст свёрнут, показать
     
  • 4.35, auk (?), 06:16, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как же так?
    https://github.com/git-for-windows/git/releases
     
     
  • 5.54, Аноним (-), 20:11, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ага, почти stable
     
  • 4.63, Led (ok), 02:47, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вы, вендузятники, должны страдать.
     

  • 1.24, ferux (ok), 21:48, 28/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    к вопросу по GUI к git:
    ничего ещё не появилось, что может нормально файлы перемещать/переименовывать с сохранением истории изменений?
     
     
  • 2.53, all_glory_to_the_hypnotoad (ok), 20:09, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    давно всё появилось.
     

  • 1.25, fleonis (?), 22:03, 28/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    fossil forever
    Там все просто, а если знаешь sql то легко решать проблемы с репозиторием
     
     
  • 2.31, Crazy Alex (ok), 01:56, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для простых случаев - хорошо, когда легкои  просто. Но Git настолько распространён, что не уметь его всё равно нельзя. А раз так - зачем возиться с лишней SCM, которая кроме простоты (в данном случае невостребованной) ничего предложить не может?

    Хотя такой, как у фоссила, гибрид проекта в git с вики, пожалуй, мог бы пригодиться по мелочи. Надо глянуть, наверняка кто-то уже сделал подобное.

     
     
  • 3.50, fleonis (?), 15:12, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На счёт не уметь гит согласен: куда не сунься, все на нём.

    Но я уже несколько проектов делаю на fossil, ещё не упёрся в отсутствие функционала. Какие там функции отсутствуют, которые нужны или которые есть в гите?

    Там не только вики, там еще и пользователи и просмотр когда и багтрекер :-)

     
     
  • 4.55, all_glory_to_the_hypnotoad (ok), 20:17, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >  Какие там функции отсутствуют, которые нужны или которые есть в гите?

    Например, rebase как он сделан в git. Без этой фичи (d)VCS совсем не нужна для работы с кодом.

     
     
  • 5.57, Crazy Alex (ok), 23:05, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вообще-то есть масса workflow, где rebase особо не используется. Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова, после чего ветка убивается.
     
     
  • 6.58, all_glory_to_the_hypnotoad (ok), 23:40, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вообще-то есть масса workflow, где rebase особо не используется.

    если кодить не ~ хеллоу ворлд, то таких workflow нет. Конечно, можно не пользоваться ребейзом и делать как-то иначе, но это от неопытности разработчика и/или из-за ограничения используемой VCS.

    >  Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова

    Цикл разработки почти всегда делится на мелкие задачи, но это деление в основном последовательное, а не паралельное. Т.е. нельзя насоздавать сразу N веток и пилить в них одновременно несколько мелких задач. Тут можно развести много бла-бла-бда на тему тщательного планирования и поэтапного выполнения работы, но это невозможно для сколь- нибудь сложного проекта. И это тупо неудобно.

    Если ребейзом не пользоваться, то реп сразу же становится помойкой из комитов с коментами типа "fix", а если часто налегать squash, то в сборище беспощадных и бессмысленных мегакоммитов. В общем, во всех вариантах без ребейза реп превращается в тупой инкрементальный бэкап.

     
     
  • 7.59, fleonis (?), 00:32, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Там есть приватные ветки. Они только на один репозиторий. Их тоже можно запулить в другой, только нужно указать спкцом, что ты этого хочешь.

    По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит. А можно просто голову создать, потом закрыть и все, они останутся в истории, будут выглядеть как ветка, только без имени

    На fossil он сам и sqlite

     
     
  • 8.71, all_glory_to_the_hypnotoad (ok), 17:32, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, это как Вот, есть, например, два последовательных коммита A и B над ... текст свёрнут, показать
     
  • 7.61, Crazy Alex (ok), 01:31, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Разумеется, в основном последовательное деление - но какая разница? Главное, чтобы фичи были достаточно небольшими, не первращаясь в монстров при squash - ну так оно при скраме так или иначе полезно. И зачем в каждой ветке пилить несколько задач? Одна задача - одна ветка - один коммит в дев-ветке в итоге. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк). Сам, правда, rebase гонял в хвост и в гриву - но ровно потому, что имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами - просто для своего удобства, как замена stash, а уже потом выгребать из этого нужное. Коллеги без него обходились и обходятся.
     
     
  • 8.64, arisu (ok), 08:54, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    о, брателло а то я думал, я один такой ... текст свёрнут, показать
     
  • 8.75, all_glory_to_the_hypnotoad (ok), 18:40, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Такое в разработке проекта на несколько М SLOCов бывает почти никогда, одна фича... текст свёрнут, показать
     
  • 4.56, Crazy Alex (ok), 23:01, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я имею в виду, что гит всё равно знать приходится. А когда его знаешь уже нет необходимости в "чём-то попроще" - он,  в общем, не сложен, просто кривая освоения крутовата.

    Что до пользователей и багтрекера - оно по факту настолько минималистично, что если понадобились пользователи - значит, нужно что-то покрупнее. А для себя вместо багтрекера и файлика .org внутри репы хватает. А вот вики в комплекте - удобно, чтобы всякие нюансы проекта фиксировать даже когда полноценное что-то поднимать лень. Хотя если есть дисциплина и желание - можно всё в доксигене держать, даже красивее выходит.

     
     
  • 5.60, fleonis (?), 00:46, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Так вот fossil и есть покрупнее. Например если над проектом работают четыре человека, то как пользователей держать? Я у себя на vps запустил сервер fossil сделал перенаправление на его порт с определённого адреса в ngnix и все, теперь, если я хочу новый репозиторий создать, с пользователям и всеми наворотами, то просто создаю там его файлик и все. Получается полноценный сайт проекта за три минуты (пока дизайн выберешь и я его немного кастомизирую иногда).

    Или, например, маленький проект для офиса. Просто запускаешь сервер на своём пк и к тебе могут заходить по ip писать баги и вики - какие-нибудь пояснения...

    А с доксигн - это уже настраивать надо... К тому же если написать очень много код не видно :-) меня это в нём раздражает. Маленькая функция, а доков больше чем кода...
    Особенно если хочешь чтобы на двух языках :-)

    Кстати, на мой взгляд, единственное что я бы хотел видеть ещё в fossil - интернационализация. Но, похоже, автор со мной не согласен, мол надо разработку вести только на одном языке, а не на пяти :-)

     
     
  • 6.62, Crazy Alex (ok), 01:49, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вот насчёт интеранционализации я полностью с автором фоссила согласен. Впрочем, я вообще люблю минимизировать количество сущностей (и поэтому предпочитаю не связываться с fossil, зная git). Если человек занимается IT - то английский он знать обречён, а раз так - нечего лишний раз раскладки дрёгать и пытаться тащить русскоязычные кальки с терминов.

    А насчёт проектов - я верю, что бывают проекты "на один раз", но я видел только два варианта - либо есть один разработчик, либо какая-то организация/команда. В первом случае в трекере и пользователях смысла нет, а во втором один хрен нужно поднимать инфраструктуру, в которой потом только проекты новые заводят. Тут фоссил как раз не очень, так как в нём все проекты получатся совершенно изолированными, в то время как тот же гитлаб или мантис позволит нормально держать взаимосвязи.

    Насчёт офиса - ок, но там непонятно, зачем к этим вики и трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну и всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много мороки - либо оно не поднялось когда надо, либо вырубил кто-то машину... Вещи общего пользования должны быть на местном сервере или, на худой конец, где-то на VPS или в облаке. Хотя, конечно, иногда народ копейки экономит - но я бы скорее таких послал.

    Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы ради того, чтобы код документировался и это каким-то инструментом проверялось. И там он удобен тем, что текстовая болтовня хорошо увязывается с кодом - ссылки и т. п. И я не имел в виду, что большие объёмы текста надо совать в исходники - делаешь отдельные файлы да ссылки на них в содержании. Мороки больше, чем с вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда в голову весь код уже даже близко не помещается, и максимум, что можно объяснить новичку - общую архитектуру.

     
     
  • 7.65, arisu (ok), 09:01, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну чего спорите‐то? фоссил — не гит, и не задумывался, как замена гита же. у фоссила есть зато уберфича, которой у гита нет: он весь состоит из одного бинаря, а репозиторий — из одной sqlite-базы. бывают ситуации, когда это может быть нужно.

    а в остальном — dvcs как dvcs.

    2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись да делай свои замены commit, rebase и прочих, если хочется. в смысле — все «кирпичи», из которых высокоуровневые команды построены, спокойно доступны в командной строке.

     
     
  • 8.67, fleonis (?), 12:08, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, чего-то я Хватит opennet заси Это кстати круто - Хм Я не вникал ... текст свёрнут, показать
     
     
  • 9.68, arisu (ok), 12:12, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а его и не надо трогать, git имеет низкоуровневые команды для манипуляций с базо... текст свёрнут, показать
     
  • 7.66, fleonis (?), 12:02, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сам сначала хотел ему написать, потом подумал и не стал, действительно не нужно ... большой текст свёрнут, показать
     

  • 1.26, ferux (ok), 22:20, 28/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Во! Дельную штуку добавили ещё: https://git-scm.com/docs/git-worktree
    Теперь можно как в SVN нормально работать параллельно в с несколькими ветками большого репозитория, без необходимости выкачивать его несколько раз из bare
     
     
  • 2.32, Crazy Alex (ok), 02:01, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем его несколько раз выкачивать? Склонируй выкачанный, оно по умолчанию ещё и хардлинками всё сделает. разве что origin придётся подправить в клонах. А постоянно прыгать между деревьями... не, ну тоже вариант, конечно, но, например, IDE спасибо не скажет, make тоже.
     
     
  • 3.48, arisu (ok), 14:58, 29/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А зачем его несколько раз выкачивать?

    прёт его, видимо.

     

  • 1.73, ALex_hha (ok), 17:56, 30/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf .git, все остальное легко откатывается

    значит вам очень круто повезло. А вот push с --force не такая веселая штука. И потом узнавать из n разрабов а у кого же самая свежая версия и все собирать до кучи - не так весело.

    Советую прочитать для общего развития - http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

     
     
  • 2.74, arisu (ok), 18:22, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > значит вам очень круто повезло. А вот push с --force не такая
    > веселая штука. И потом узнавать из n разрабов а у кого
    > же самая свежая версия и все собирать до кучи - не
    > так весело.

    а ещё можно мошонку гвоздями к доске прибить. виноваты будут, понятно, гвозди и молоток.

     
     
  • 3.76, ALex_hha (ok), 21:52, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> значит вам очень круто повезло. А вот push с --force не такая
    >> веселая штука. И потом узнавать из n разрабов а у кого
    >> же самая свежая версия и все собирать до кучи - не
    >> так весело.
    > а ещё можно мошонку гвоздями к доске прибить. виноваты будут, понятно, гвозди
    > и молоток.

    команда есть и она "опасная". Или вы потом скажите, так виноват Вася, что не прочитал 600 страниц pro git ;) Но всегда виноват админ :D Порог вхождения у git по сравнению с svn/hg намного больше и отрицать это глупо

     
     
  • 4.77, arisu (ok), 22:01, 30/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > команда есть и она "опасная". Или вы потом скажите, так виноват Вася,
    > что не прочитал 600 страниц pro git ;)

    откуда дебил‐вася узнал о «--force» вообще? тупо скопировал из интернетов, не пытаясь понять? молодец вася, он дважды дебил. или таки заглянул в документацию — и не прочитал предупреждения? трижды дебил.

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

     
     
  • 5.80, ALex_hha (ok), 17:34, 31/07/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> команда есть и она "опасная". Или вы потом скажите, так виноват Вася,
    >> что не прочитал 600 страниц pro git ;)
    > откуда дебил‐вася узнал о «--force» вообще? тупо скопировал из интернетов,
    > не пытаясь понять? молодец вася, он дважды дебил. или таки заглянул
    > в документацию — и не прочитал предупреждения? трижды дебил.
    > от дебилов защиты не существует, дебилы очень изобретательны в своём дебилизме. любая
    > попытка «защититься» от дебила дебилом с лёгкостью обходится, а нормальным людям
    > доставляет массу неудобств.

    какая разница откуда он узнал, твоя задача быстро все исправить, а не с пеной у рта кричать, что это Вася дебил и что он не прочитал n страниц мануала. Документация в git то еще удовольствие :D

     
     
  • 6.81, arisu (ok), 17:37, 31/07/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > какая разница откуда он узнал, твоя задача быстро все исправить

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру