Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Всем привет)
Наткнулся на днях. В одном подкасте ( пилотный выпуск подкаста от Хекслета — www.youtube.com/watch?v=t2X5E8de3OQ ) рассказывали про сабж.
gitless.com
github.com/sdg-mit/gitless
Стало интересесно, насколько оно удобнее (проще) самого гита? и оно стабильное или еще нет? ибо судя по гитхабу есть только т.н. пре-релизы. Кто-то уже юзал? Какие впечатления?
Какие впечатления
Ехал Gitless через Gitless
Видит Gitless в Gitless Gitless
Сунул Gitless Gitless в Gitless
Gitless Gitless Gitless Gitless
У этих ребят соглашение чуть чуть странное www.gitkraken.com/eula особенно пункт 4.
> ... related to the Software or any other Axosoft product or service.
А Ви думали, що як лишите їм feature request, а вони його виконають, то потім отримаєте % з продажу чи частку в компанії? :)
Я про це: " ... Axosoft and its licensors own all right, title and interest to the Software and any modifications, ideas, or recommendations provided by You, together with all associated intellectual property rights. You assign to and agree that Axosoft shall own and have the right to exploit and including in the Software any suggestions, enhancements requests, feedback, recommendations or other information provided by You related to the Software or any other Axosoft product or service. ...“. Ці рядки можна по різному трактувати, адже інформація про коміти, проекти, ... теж “provided by You”..
Цей конкретний пунка складно трактувати неправильно. Там відразу за «provided by You» йде «related to the Software or any other Axosoft product or service». Якщо не забувати, що таке «the», та у розділі 1 уточнити, що таке «Software», стане ясно, що мова йде про фідбек на продукти Axosoft, а не про інформацію, яку я опрацьовую за допомогою їхніх продуктів.
Іншими словами, якщо я придумаю круту фічу до їхнього продукту, то продукт не стане моїм, всі права лишаться в них, включно з правами на придуману мною фічу.
Хлопці з gitkraken-у використовують трохи ширше поняття ніж фічі —
provided by YouЦі три слова вживаються ще у пункті 2.2, що має рядки:
You acknowledge and agree that Axosoft shall own all right, title and interest in and to all intellectual property rights (including all derivatives or improvements thereof) in the Software and any suggestions, enhancement requests, feedback, recommendations or other information provided by You or any of Your agents, contractors and outsourcers relating to the Software.Оскільки коміти та вихідні коди також є"other information provided by You«(привіт синхронізація) та були оброблені за допомогою «the Software» (привіт побудова дерева комітів) то вони мають «relating to the Software» з позиції викорисання. І в умові немає цього уточнення. Хоча я не маю юридичної освіти, лише один симестр технічного правознавста в КПІ, я очікую бачити в ліцензійній угоді чітко визначенні положення/формулювання, що не можуть двояко трактуватись.
Я не кажу, що gitkraken погана річ, навпаки — це один з найкращих візуальних редакторів для лінуксу, проте їх ліцензійна угода трохи дивна, і через це ним користуватися стохи лячно. Наприклад, угода MIT подібних рядків в собі не містить.
З іншого боку, ліцензійна угода від google.com, також дивна (www.google.com/policies/privacy/. Вона має рядки, наприклад
telephony log information like your phone number, calling-party number, forwarding numbers, time and date of calls, duration of calls, SMS routing information and types of calls(Privacy Policy -> Information we collect -> Log information).
І якщо у випадку з гуглом важко знайти інший такий якісний пошуковий сервіс, то з графічним клієнтом для гіта такої делеми немає.
Звісно, рядки з ліцензійних угод що цитатами приведені вище, були включені в угоди за для користуванча, і з найкращих намірів, проте як ми знаємо (історія) — Найкращими намірами встелена дорога в пекло.
relating to the Software
Я так розумію, ці слова обмежують зміт всього попереднього переліку в реченні. Тобто комміти не відносяться безпосередньо до git-клієнту, т.я. жодним чином не впливають на нього. Але тут краще юристів спитати, чи так би воно трактувалось у суді...
хм, пытаются из git сделать mercurial, но чтобы он остался git’ом?
А где тогда безымянные ветки? :)
Почитал документацию, не пробовал. Впечатления:
1. На коммит, явное нацеливание на подход «я тут твёрдо уверен, что именно собрался менять». Не знаю, как у кого, но в продуктовой разработке это нетипично. Более часто, что формально мелкое изменение вверху начинает хотеть чего-то в нижележащих слоях, или на том же слое в соседних файлах, а ещё потянет за собой пару-тройку рефакторингов. Уже готовые правки (даже если не компилируются) откладываются (stash, временные ветки), чтобы приступить позже. Для ясности понимания изменения из одного файла могут поступать только частичные изменения. В gitless всё это похерено, видимо, в предположении на самые простые правки. Мне это подозрительно.
2. fuse это замаскированный вариант или rebase, или цепочечного cherry-pick. В принципе, это достаточно грамотная идея (именно что цепочка cherry-pick это нередкий вариант). Тут, да, они ухватили популярный юзкейс.
3. switch с сохранением изменений для каждой ветки отдельно это тоже интересный вариант, но при этом желательно иметь и дополнительное управление этим. Сейчас оно плохо потерпит вмешательство в сложных случаях напрямую через git. Я так понимаю, это сделано для ситуации типа «у меня тут тонна тяжелоуправляемых настроек в IDE, сплошные явные пути, я не могу это просто так перенести на другие пути через git clone, а тут прибежало начальство и требует срочно отложить все незавершённые мержи и лечить проблему кривых рук Марьи Петровны с чушью в поле номера». Тогда непонятно, почему они не начали с версии под Windows, где подобные проблемы обычно в разы тяжелее.
Это для тех кто ниасилил git?
так во многих IDE уже есть своя интеграция с гитом...
да, расовые линуксоиды которые даже порносайты смотрят с командной строки такого не поймут. :)
почему ненавидят? просто её никто не портировал и она там не нужна.
Sourcetree, GitX, gitk, GitKraken (новый, модный, молодёжный), tig в консоли...
GUI клиент вообще не особо нужен.
Рассовый линуксоид ломает Пентагон командой ipconfig.А рассовый виндузятник взламывает Пентагон кликаньем мышкой по красивой красной кнопке с надписью «Взломать Пентагон»)
Тыча по плиткам на телефоне. Жаль, что под WP8.1 проводника нет...
ipconfig.Виндузятник спалился.
Но вот что меня удивляет, почему так линуксоиды ненавидят TortoiseXXX? Может потому, что это один из немногих продуктов с действительно удобным Гуем.просто если ты пишешь/правишь код, то и коммитишь этот код сразу в редакторе/IDE, зачем тебе файловый менеджер и черепашки? не вижу в этом ничего удобного.
ну я же не раз говорилкак же я мог такое пропустить :D
что формошлепством не занимаюсьась? к чему тут это? вы не пишете код? копируете файлики туда-сюда мышкой?
можно и возможностями IDE пользоваться, но это часто просто неудобноа какие IDE используете?
Студию
иногда PyCharm, когда нужен Pythonа почему не Python Tools for Visual Studio — microsoft.github.io/PTVS ? ну раз уж раз уж студию юзаешь. Просто интересно)
или Bashа для баша для студии есть такой плагин — visualstudiogallery.msdn.microsoft.com/...
Студия последнее время напрягает, слишком она тяжелая сталасогласен) но ведь можно например установить VS 2010 (или 2012), причем Shell Integrated версию, на которую доустановить нужные расширения для нужных языков.
я устанавливал VS 2010 shell integrated не ради с++ и даже не ради си-шарпа, а ради F# и Nemerle) ну и + Python Toоls и IronRuby.
А для c/с++ из тех IDE, что смотрел, мне больше всего понравилась Falcon С++ sourceforge.net/projects/falconcpp .(правда я только учебные проги на Си смотрел/писал).
з.ы. а самая нормальная поддержка плюсов наверное была только в Visual Studio 6))
2. Умение юзать разные компиляторы.кстати недавно посмотрел на Code::Blocks — так там по-видимому наиболее полная поддержка разных компиляторов для с/с++ из всех идешек наверное) Плюс поддерживает фортран и D (и есть еще какие-то доп. плагины). Ну и видел инфу, что для code::blocks пишут плагин для питона.
а вот как насчет
1. Качество интеграции отладчика и его отзывчивость.в Code::Block не знаю, не проверял, но по идее должно быть хорошей, ибо эта идешка вроде считается одной из лучших ide для плюсов.
Моснтры типа Еклипса идут лесом.плюсую)
черепаха под гит несколько неудобная. Особенно когда ожидаешь такого же удобства как в варианте для svn
Разве Git Extensions не удобнее?
Самое главное я в файловом менеджере вижу, какие файлы поменялись, какие закоммитить, какие нет, какие добавилить или удалить и это всё подсвечено разными иконками.Так это, git status же...
И с большим удовольствие рассматривать простыню текста.
Он вообще-то про status говорил, а не diff.
Хотя и дифф тоже полезно внимательно просмотреть.
Понимаю.
Похоже, нет.
Слушай, ты вообще не пользуешься файл-менеджерами, только в командной строке с регекспами все делаешь?
А оно обычно таки эффективнее. Менеджеры это свалки разбирать, типа ~/Downloads/.
И с большим удовольствие рассматривать простыню текста. Понимаю.Простыня текста может быть если ты коммитишься раз в год или у тебя задачи, которые требуют одновременного изменения сотен файлов (в чём я сомневаюсь). Если периодически нормально комититься, то никаких простыней не будет.
Слушай, ты вообще не пользуешься файл-менеджерами, только в командной строке с регекспами все делаешь?В основном консоль, иногда mc, я не знаю зачем в линуксе пользоваться оконными менеджерами
Не юзал, но осуждаю.
Первая мысль — это что, набор алиасов?
Вторая — а какая разница, запоминать нативные гитовые команды или эти.
Третья — гит сложный? (во всяком на уровне подмножества команд, которые вводятся на уровне автоматизма)
Люто плюсую, не покидал вопрос: на поркуа это вот все?
Не юзал, но осуждаю.Это зря. Как минимум одна фича этого “набора алиасов” очень даже заслуживает внимания:
“The main thing to understand is that in Gitless a branch is a completely independent line of development. Each branch keeps its working version of files separate from each other. Whenever you switch to a different branch, the contents of your working directory are saved, and the ones corresponding to the branch you are switching to are retrieved.”
это типа как набор алиасов для stash / unstash при checkout’е?
Там они сохраняют, как пишут, не только локальные изменения, но также незавершённые слияния и тому подобное. Так что это шире, чем stash/unstash.
гит очень сложная и неинтуитивная система, иначе бы стековерфлоу не разрывался от вопросов.
основной критицизм гита сводится к тому что его создавали не для программистов а для мейнтейнеров /администраторов распределенных проектов, которые занимаются слиянием кода из многих параллельных бранчей. его терминология неинтуитивна а документация ужасна.
гит очень сложная и неинтуитивная система
Если не вбивать в голову каноны некоторых извращённых конкурирующих систем, git становится прост и понятен ;)
Мне он оказался в разы понятнее Hg, SVN, некоторых прочих. А основная критика идёт в стиле «я вот XX быстро понял, а тут...» в качестве XX, как правило, SVN или Hg. Только я на это смотрю так, что после этих систем «а Ватсон без трубки уже не мог».
основной критицизм гита сводится к тому что его создавали не для программистов а для мейнтейнеров /администраторов распределенных проектов
Именно что для программистов. В «распределённых проектах» не нужна, например, staging area, которая изначально была killer feature гита как для программиста (сейчас Tortoise впихивает её куда угодно, но в родных клиентах её до сих пор больше нет ни у кого).
Ну то, что это надстройка (а не замена), это плюс. В остальном не знаю. Мне и git нормально. Я там использую всего-то пару команд.
такая же сысль посетила, обычно если все ок и нет никаких конфликтов и прочих из ряда вон ситаций, это создал бранч, долил из дого бранча в другой, загрузил изменения , смерджил. как то так и зачем там надстройки.
Roman Kr
Anthony Haman
Serhii Kovalchuk
Дмитро Киричук
Volodymyr Fedorchuk
Дмитро Киричук
Serhii Kovalchuk
undefined pointer
Valentin Nechayev
Valentin Nechayev
anonymous
Олександр Петров
Eugene Varava
anonymous
Леонид Мартынюк
Егор Добровольский
schwarzlichtbezirk
Alexander Yakushev
Ilya Trushchenko
Andriy Maletsky
Illia Khabibrakhmanov
Max Bright
Anton Fimin
Konstantin Strukov
Странный Обыватель
Victor Mikhaylov
Gennady Dogaev
Oleksii Pavlov
61 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів