Доступен выпуск cGit-U 0.1.3, web-интерфейса для просмотра Git-репозиториев...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54208
Ну и кому нужно это нинужно, когда существует гитлаб?)
Ага. Мне не нужно, значит не нужно никому!
Гитлаб мне не нужен, значит никому не нужен.
Все жду, напишет ли кто-то к какой-нибудь новости, что это ему _нужно_, а значит - не нужно никому, чтобы он единолично владел прелесссстью.
Гитлаб нужен только обладателям 128 гигов оперативной памяти, которой все равно не хватит на всех.
Фантазёр$ docker stats gitlab --format {.MemUsage}}
2.792GiB / 31.36GiB
Хорошо ты установил гитлаб, а теперь попробуй там поднять парочку проектов, на несколько десятков разработчиков.
гражданин, начальника, пустил пользователей, как вы и просили , но гитлаб таки влез в отведенные ему 8 гб, а еще чото осталось даже , может насяльника путает и/или ставит ранер на хост с гитлабом?
> Гитлаб нужен только обладателям 128 гигов оперативной памяти…и это только на стороне браузера.
Кстати, там меню из угла в угол с каждой новой версией уже перестало переезжать?
Это не социалка, а просто маленький интерфейс, или нет.
Блин, ну когда уже сделают, что-бы минусовые всхрюки вниз уходили?
"нормальный режим" с сортировкой.
Оно немного как попало, иногда минусы это просто минусы.
> Ну и кому нужно это нинужно, когда существует гитлаб?)Гитлаб тормоз что писей и гиг памяти в браузере жрет.
У меня на серваке GitLab уже поимел 83G дискового пространства и это не считая самих репозиториев. Да и обновлять версии, выходящие раз в 2 недели, я уже устал.
А если не секрет, что занимает эти 80ГБ?
gitaly
gitlab
gitlab-shell
gitlab-workhorseвсе это валяется в исходниках (клоны исходных реп), так как по выходу очередной версии надо мержить новшества (веток с различными версиями за несколько лет накопилось много).
Разумеется первая установка занимает не более 20G.
Зачем ты его из исходников собираешь? Сам себе мозги делаешь, когда можно взять готовый преднастроенный образ.> Разумеется первая установка занимает не более 20G.
Первая установка занимает меньше двух гигов, кек
> когда можно взять готовый преднастроенный образГлавное -- не заглядывать на кухню, где его готовили...
От это точно. Только что от станка и ну такие запахи из той кухни, что чур чур.
О, свежий примерчик к тому шеф повару - https://gitlab.com/gitlab-org/gitlab/-/issues/32204Без комментария.
Это фигня. Вот #14560 — это да, баг-эпопея.
Четыре года не могут найти ответственного, чтобы отключить фичу, которая профессионалам только мешает?
Вот это прикол... Гитлаб вслед за хабом наломал такой JS что мне в старом ФФ теперь видно лишь чистый белый пустой лист вместо ишшуэ. А казалось - софт для разработчиков... (
> Это фигня. Вот #14560 — это да, баг-эпопея.Это позорище... Так они ж ещё там и пишут "не фиг исправлять - если вручную подвести курсор, то высвечивается же абсолютная дата - чего вам ещё надо".
Я не встречал людей старше 14 лет, для которых проблема моментально в уме прикинуть очень примерно как давно была какая-то абсолютная дата. Но кто-то ж, бл@, придумал что "пользователям так лучше" (чтоб этим людям в каждом ценнике была сумма прописью!). И это как зараза распространяется!
Из личного опыта - есть одна программа (не буду "рекламировать" название) для работы с GPS-трекерами. И у них метки на карте тоже с относительным временем(!) и разработчики не видят в этом проблемы (я уж несколько раз развернуто объяснял и просил хоть опцию сделать)!
На карте стоит точка где находился объект, около точки написано "только что" (или "час назад"). Объект по идее должен ехать по дороге, но точка стоит на месте и надпись не меняется: поди угадай, то ли что-то случилось, то ли просто не было новых данных или ещё что. Абсолютное время хотя бы дает информацию когда ж реально было.
Ну и это же говно и при отображении трека, то есть невозможно точно определить когда объект был в каком-то месте. Между "час назад" и "два часа назад" - погрешность час! Для едущего автомобиля, например, это, блин, с точностью до региона... А разрабы и/или дизайнеры или кто там у них этим занимается считают, что "так лучше". И gitlab и им подобные таким людям же служат примером...
Поставь gitea и не люби мозг
Gitea хорош для совместной разработки, а тут просто UI для публикации.
Про gitea это был ответ тебе на жалобу про GitlabИспользую gitea+drone, имею фактически все тоже самое, что дает Gitlab
> Да и обновлять версии, выходящие раз в 2 недели, я уже устал.Панемаю, очень сложна три команды ввести
docker pull
docker rm
docker run
я в живую запускаю GitLab. Докер - это не спортивно.
> не спортивноПонял вас, товарищ участник специальной олимпиады, вопросов больше не имею.
Предпочитаю владеть, на не пользоваться.
ну тогда вперед писать свое, а гитлабчик на место положите, у нас недобор , на всех не хватает
Молодец, я тоже люблю тратить время на решение проблем с ПО, которые его производитель давно автоматизировал.
Вместо того, чтобы устранять проблемы в корне, кто-то занимается автоматизацией их решения!Это всё, что нужно знать про современных разработчикв в тренде.
А почему не FastCGI ?
Можно и FastCGI (все что поддерживает web-сервер).
Да ну ваш Гит. Ну модно, и только что - можно подумать единственная система контроля версий? У меня вот своя, на bash (ога!) и никакого мелкософта!
Какое отношение майкрософт(кроме твоего безумия) имеет к git'у?
А это лечат, простити? Может имейл подкините?
> Какое отношение майкрософт(кроме твоего безумия) имеет к git'у?То ли очень толсто, то ли - очень тупо..
Очень толсто -- это позиционировать bash как замену git'у. Очень тупо -- считать что использование git'а можно противопоставить с "никакого мелкософта". Хотя второе, возможно, тоже не тупо, а толсто.Ты, наверное, комментом промазал и не туда ответил?
> Очень толсто -- это позиционировать bash как замену git'у. Очень тупо --
> считать что использование git'а можно противопоставить с "никакого мелкософта". Хотя второе,
> возможно, тоже не тупо, а толсто.
> Ты, наверное, комментом промазал и не туда ответил?Ответил я туда куда и планировал - к комменту о неимении отношения микрософта к гиту
Окей, давай прервём этот порочный круг взаимного троллинга.Какое отношение имеет ms к git'у? У тебя есть информация о чём-то, кроме github'а и VFS? (Или как там называлась их фс построенная на git'е?)
Малыш, ты путаешь один из сотен git-хостингов(github) и git.
MS купили Github, но к git'у это не имеет отношения вообще никакого.
Git разрабатывается при участии Software Freedom Conservancy, некоммерческой организации созданной до твоего рождения(в 2006 году) и контролирующей разработку таких проектов как QEMU, BusyBox, Samba, Wine, git и других
Если что, git на чистом bash тоже есть.
https://git.sr.ht/~sircmpwn/shit
Не bash, а POSIX shell! Читать научись!
Oh, shit.
Что-то до полного функционала git оно несколько не дотягивает, мягко говоря. Больше похоже на закат солнца вручную.
Just for fun, ради эксперимента. В аннотации так и написано.
> У меня вот своя, на bash (ога!)а кроме вас ЭТИМ кто-нибудь пользуется?
Это вообще законно?
Предлагают ставить из svn. Они там точно для гит гуй запилили?
для Git, для Git, не беспокойтесь, вот он в работе https://cgit.radix.pro/
можно скачать вот отсюда https://ftp.radix.pro/pub/cgit-ui/
>вот он в работеЕсли честно, то заголовок, причём, пустой, занимающий 50% экрана - это как-то совсем не хорошо. Так можно потенциальных клиентов совсем в уныние вогнать.
Этот заголовок, как и множество других вещей, описывается в конфигурационном файле /etc/cgit-ui.rc и пользователь может настроить внешний вид сайта на свое усмотрение. Кроме того, в настройках он может добавить аналитику от Google, Yandex и других поисковиков, а также добавить к своим репозиториям диалог Donate (с разными заголовками и целями для каждого из ваших репозиториев).Более того, используя cGit-ui вы можете создать все условия для индексации ваших исходников и Markdown документации так, что будете всехда представлены на первых страницах Google или Yandex.
Я тоже когда-то поставлял продукт с миллионом настроек, о которых мало кто догадывался, а потом получил стрелу в колено. Демо должно быть фичастым и красивым, бро.
Да и почему не html, css, а какой-то конфиг? Логичнее же шаблоны иметь. Или наоборот - выдавать html и встраиваться в какой-нибудь Друпал или Вротпресс.
Вы просто не прочитали ничего из того, что написано в документации:https://csvn.radix.pro/cgit-ui/trunk/README.md/
https://csvn.radix.pro/cgit-ui/trunk/doc/cgit-ui.rc.5.mdЗдесь представлена лишь новость о выходе пакета.
Однако вы даете советы Вселенского масштаба даже не соизволив узнать, о чем именно вы говорите.
Не, не читал. Просто не дошёл до этой стадии заинтересованности. Новость вялая, зашёл на сайт - сайт вялый. Я ничего против не имею - более того - мне нравится ваш продукт. Но подача его вызывает боль.
>>https://csvn.radix.pro/cgit-ui/trunk/doc/cgit-ui.rc.5.mdНу, да. У вас всё противоположно тому что я сказал двумя каментами выше. На каждую новую хотелку придётся заводить фичу в cGit, новую переменную и т.п. Дело хозяйское.
>svn checkout svn://radix.pro/cgit-ui/tags/cgit-ui-0.1.3 cgit-ui-0.1.3Как забавно, впрочем ничего удивительного. Гит без помощи нормальных СКВ беспомощен. Вот как минимум ещё разработчики SuperTuxKart хранят ресурсы в svn-сервере на sf.net, а всё потому что гит так не может, подавится.
https://git-lfs.github.com/
Костыль
> КостыльБезусловно, но всё же гит так сможет и не подавится.
>>svn checkout svn://radix.pro/cgit-ui/tags/cgit-ui-0.1.3 cgit-ui-0.1.3
> Как забавно, впрочем ничего удивительного. Гит без помощи нормальных СКВ беспомощен. Вот
> как минимум ещё разработчики SuperTuxKart хранят ресурсы в svn-сервере на sf.net,
> а всё потому что гит так не может, подавится.Вебкитовцы( привет, сафари ) тож код в тех краях хранят, в гите - либо неофициальные зеркала, либо - раз в неделю / день код из не_гитовской репы сливается
Было интересно попробовать что-то кроме гита, но, скажу я вам, при не очень хорошем тырнете( а то и скорости отдачи на стороне репы ) качать оттуда 1+ Гб - было то еще развлечение( лично у меня оно растянулось на неделю )
Но вроде уже получше стало
> работающий на сервере в цепочке Nginx - uWsgi - cgit-ui.cgiОй, а у меня fcgiwrap вместо uwsgi. Так нельзя, да?
А, это какой-то cgit-u. Пардоньте, обознался. У меня нормальный человеческий cgit.
Да запросто, в REDADME.md пример настройки c uWsgi. Nginx работает и с CGI и c FastCgi. Напишите свой конфиг для Nginx с fasccgi_params и все будет нормально. Кстати, не было времени настраивать разные конфигурации, если вы поделитесь настройками FastCGI, сообщество будет благодарно. Вот пример https://www.nginx.com/resources/wiki/start/topics/examples/f.../ но надо потрудиться.
Трудиться лень, просто делюсь:
root /usr/share/cgit;location /cgit-css/ {
alias /usr/share/cgit/;
expires max;
}location /robots.txt {
root /usr/share/cgit;
expires max;
}location / {
fastcgi_param DOCUMENT_ROOT /usr/lib/cgit/;
fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
fastcgi_param PATH_INFO $uri;
fastcgi_param QUERY_STRING $args;fastcgi_pass unix:/var/run/fcgiwrap.socket;
}Да, это для cgit из дебиановской репы. Под cgit-u подгоняйте сами, если надо.
эт понятно. https://wiki.archlinux.org/index.php/Cgit
Обожаю, когда сайт проекта "что-то-там-UI" и ни одной картинки этого UI в действии. Очень показывает насколько тонко и основательно проработали создатели ядро проекта UI, прежде чем начать кодить как макаки.
Вместо картинок, по ссылкам в новости, можно видеть работающий саййт. Зачем нам картинки? https://cgit.radix.pro
После интерфейса Gitea выглядит более чем убого, про UI/UX тоже не начинали пытаться думать. Чем оправдывается весь шум вокруг изделия? Съест так мало памяти, что можно поставить на старый смартфон?
Желчегонным действием.
Тогда и тут работа не завершена.
Серьезно, какие цели предследовали? Ради фана или приносить пользу? Даже gitweb мало того что дает тот же "минмалистичный" интерфес, так хотя бы не пестрит везде 9упоминаниями nginx - просто честный CGI и все.
погодите ка.....
А зачем в 2к20 , уиня(ui), да еще и на Ц? вопросов нет, круто, наверно даже локально полезно где то, но какую задачу, общественную, вы решали?
представил себе, вышел на работу , а там это.... я конечно не из пугливых, но свой флоу лучше держать в строгости, а не писать на каждый чих свой ispmanager (кто в поддержке бывал понимают о чем я ), ниша сомнительна, хомячки поставить не смогу (конфиги сами ищите, хоть бы в православный докер обернули - хоть кто то бы посмотрел)
Айти ходит по кругу, переизобретая одно и то же. Как заметил Роб Пайк (utah2k): страннейший парадокс, самая инновационная область, а внутри — никакого реального развития.
Для perl'a написали огромный CPAN'ище. Где он теперь? На свалке.
Для Ruby написали тучу чудесных Gem'ов. Где они? Мода прошла, пора переписывать заново на node!
Только как-то довели до ума десктопные фреймворки — все повалили переизобретать окошки в веб.
Что творится во всяких гномах? У пользователя радостно отбирают даже уже имевшиеся несколько лет назад возможности что-либо поднастроить.
Firefox? Люди наработали тучу полезных расширений, у людей был workflow, что они сделали? Всё выкинули.Выполнять какую-либо нетривиальную, либо требующую обработки множества (а тем более медиа-)файлов операцию на компьютере до сих пор боль, которую не пересилить без знания какой-либо скриптоты. А программисты сидят, переписывают себе библиотеки, чтобы переписать текстовые редакторы да интерфейсы к гитам.
location ~ ^/favicon.ico$ {
root /u3/nginx/vhosts/cgit;
access_log off;
log_not_found off;
expires 30d;
}location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
вы уж простите, но сложилось чувство вы и nginx не оч понимаете
location ~* ^.+(favicon.ico|robots.txt) {
root /var/www/htdocs/cgit;
expires 30d;
}
А кто его понимает? Человек 100 на земной шар.
Язык конфигурации там совершенно жуткий.
Это вы ещё простыни правил в файлах .htaccess для Apache не видели. Некоторые веб-приложения раньше только под Apache затачивались и носили с собой километровые файлы .htaccess. Запустить их на чём-либо кроме Apache было проблематично.С nginx попроще, но тоже не идеал. И я считаю, что виноваты в этом по-прежнему веб-приложения. Если это CGI-приложение, то у него должен быть один файл, отвечающий за обработку всех запросов с человекочитаемыми URL и отдельный каталог со статическими файлами. Если бы все разработчики веб-приложений соблюдали такое правило, то никаких сложных правил в nginx было бы не нужно. Достаточно было бы парочки секций настроек для одного приложения: location /web-applicatin/ { } и location /web-application/static/ { }
Куда помещать обработку URL и прочее - отдельная тема. Лично не вижу препятствий городить целые иерархии конфигов связки из Nginx+Apache (привет от Битрикс CMS). Лишь бы разработчики эти конфиги в документации указывали (привет от UMI.CMS).