:+1: для этого и я бы предложил назвать эту особенность чашки ,, как в чашках чая....

@laplix Это может немного сбить с толку с помощью Common Unix Printing Service. Тоже +1.

кружка? купи? Или просто Пастебин?

Или просто фрагменты, я знаю, что это не причудливое имя;)

Я все еще (см. проблему с gogs) думаю, что это должен быть внешний сервис. Однако мы могли бы сделать его инъекционным в Gitea 🙂

Дополнительные особенности:

) Раздел комментариев
) Ревизии (История)
) Подсветка синтаксиса, которой нет даже в Gist
) Фильтр и сортировка

Много +1 и множество отдельно созданных отчетов об ошибках по этому предложению показывают четкую картину:

гогитс/гоги#936

с другой стороны, реализация фрагментов должна быть довольно простой.

Держите скрытое репо под названием _snippets (или подобное), каждый фрагмент представляет собой папку, папка (или фрагмент) может содержать несколько файлов. Сделанный :)

@bkcsoft На GitHub каждый фрагмент представляет собой репозиторий Git (но может содержать много файлов). Но мы можем сделать его другим.

Я не знаю, должно ли это быть частью Gitea или отдельным проектом. Если бы в Gitea было бы проще переиспользовать код.

В любом случае, мы должны иметь в виду, что многим людям (включая меня) не нравится пользовательский интерфейс GitHub для Gists. Я думаю, мы можем сделать это лучше. Должны быть категории или теги для организации сути. Должно быть легко находить и искать существующие Gists.

Содержит все фрагменты в одном репо :

Плюсы:

• Легко импортировать/синхронизировать с вашим редактором
• Довольно легко реализовать :trollface: (думаю, скопировать-вставить вики-код)

Минусы:

• Может работать медленно, если вы часто используете фрагменты
• Трудно полностью удалить фрагмент (переписать историю, нехорошо)

Пользовательский интерфейс Gist действительно отстой ... многое нужно улучшить, просто кажется, что он собран вместе ...

ИМО, мы должны содержать все, что касается фрагментов к указанному репо (если это один, иначе я весь в подмодулях или что-то еще, чтобы отслеживать их ...), это включает в себя категории (папки кто-нибудь? :trollface:) и теги

Наличие этого файла в репозитории упрощает синхронизацию с вашим редактором и упрощает поиск 🙂

@andreynering Я тоже думал о тегах, думаю, это хорошая идея.
Может быть, поместите эти теги/категории слева
Так что легко создавать и находить определенные pastebins:

Может быть хорошим кандидатом для разветвления и настройки: https://github.com/defunkt/gist

Или это, https://github.com/gmarik/Gistie

defunkt/gist — это инструмент командной строки для общения с Gist, gmarik/Gistie написан на Ruby, оба здесь не очень уместны 🙂

Предпочтительна чистая библиотека golang.

@lunny @bkcsoft в моем случае я публикую Gistie, чтобы посмотреть, как этот инструмент работает и реализовать на Gitea, а не использовать инструмент в Gitea.

Вы можете использовать его с быстрым сервером, чтобы людям не приходилось думать о пространстве. Используйте hastebin.com по умолчанию и отправляйте запросы от клиента с помощью javascript, поэтому скорость сервера не будет ограничена. Но также разрешите пользователям использовать свой собственный хест-сервер. Это может быть реализовано с помощью iframe.

Я только что нашел сегодня отличный инструмент, которым хочу поделиться с вами: fssnip.net

Добавлено к оригинальной награде. В любом случае, я считаю, что каждый фрагмент в качестве собственного репозитория, вероятно, лучший способ сделать это с точки зрения истории и модификации в автономном режиме.

Кстати, ссылка на Bountysource не работает. Вот текущий итог:

Некоторые идеи о Gist или мы называем это Cups ?

1. Один cup — это специальный репозиторий, чтобы мы могли повторно использовать все старые коды. Затем у нас есть зеркальные, разветвленные, чашки и т. Д. Типы репозиториев.
2. Каждый репозиторий типов может иметь разные вкладки (мы храним их на repo_unit). Таким образом, каждый репозиторий мог загружать свои модули во вкладки.
3. Для репозиториев cup разрешены только текстовые файлы (без папок, изображений и двоичных файлов), а имя первого файла также является именем репозитория. Например, tea.go . Основной пользовательский интерфейс репозитория cup покажет код файла и некоторые комментарии. Комментарий может быть внизу или в какой-то строке кода.
   Также у него есть описание или, может быть, классы.
4. Для репозиториев cup существует только одна проблема при создании репозитория. Все комментарии должны следовать за этой проблемой, тогда мы сможем увидеть все комментарии в пользовательском интерфейсе cup .
5. Репозитории cup могут находиться в /cups/<user_name>/<cup_name> и отдельной записи в верхнем меню панели инструментов. Во всех других местах репозиторий этого типа не будет отображаться. Но имя репозитория нельзя было повторно использовать в обычном репозитории пользователя. Этот пользовательский интерфейс может быть скриншотом @ShalokShalom или любой новой идеей. и обеспечить поиск кода, так как мы объединили его в v1.3.

Загляните в гисты, там может быть несколько файлов.

@lunny Что касается 3: с сутью я иногда использую несколько файлов, поэтому я думаю, что ограничение одним может не сработать в некоторых случаях. Кроме того, возможно, вместо принудительного расширения файла мы могли бы либо принять text/plain, либо проверить, является ли файл двоичным файлом, а затем просто предоставить ссылку на необработанный файл.

Редактировать: ptman добрался до этого первым.

Бинарные файлы для сервиса pastebin? Не хорошая идея.

Пожалуйста, не требуйте расширения файла, иначе вы не сможете поделиться make-файлом.

@ptman @tboerger @techknowlogick обновил мои комментарии.

Поскольку некоторым людям не понравилось, как мы интегрировали отслеживание времени в ядро, как насчет того, чтобы сделать pastebins внешним сервисом, который тесно интегрируется с giteas api и использует его репозитории для хранения паст?
Я думаю, что даже pastebin Githubs является своего рода внешним сервисом...

@kolaente , поэтому по умолчанию отключено. Но в качестве внешнего сервиса потребуется больше работы, чем в качестве внутреннего, так как репозиторий, проблема, комментарий уже готовы.

Обе? Итак, Github Gists вместе с собственным решением?
И Gitpin(s) для внутреннего имени?

Владелец РЕДАКТИРОВАТЬ: пожалуйста, держите обсуждения в безопасности для работы...

+1

@lunny Как насчет этого. Зарезервировать репозиторий _snippets.git , а затем разрешить внешней службе использовать его для фрагментов?

Редактировать: Таким образом, у нас все еще есть доступ к комментариям (как только это будет реализовано и объединено :trollface: )

Или .snippets.git так же, как .wiki.git ? И какой внешний сервис подходит для этого?

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

В противном случае, если бы мы реализовали сервис pastebin в gitea, мне бы понравилась идея зарезервированного репозитория, так как вставки обычно не очень много, я не вижу необходимости каждый раз создавать репозиторий, я думаю, что это было бы слишком много репозиториев через некоторое время при создании некоторых паст.

Я думаю, что можно использовать один репозиторий и новую ветку для каждой вставки.

Любая причина, по которой у нас не должно быть репо для пасты? Одна из самых крутых особенностей GitHub Gists заключается в том, что они на самом деле являются полными репозиториями, которые можно клонировать и использовать.

я тоже так вижу, 54

+1

Единственная возможность: можем ли мы просто создать кнопку, которая ссылается на пользовательский сервис pastebin?

Это дает нам несколько преимуществ: Очень быстрая разработка и настройка.
Если быть честным:
С тех пор, как я написал эту проблему, изменился ли мой предпочтительный язык, и его служба pastebin поддерживает даже всплывающие подсказки и библиотеки.

Реализация Gitea все еще возможна позже, и это (все равно) нулевые дополнительные усилия?

Я не поддерживаю внешний сервис pastebin. Причина, по которой моя компания использует Gitea, заключается в том, что она находится во внутренней сети из-за безопасности и внутреннего доступа. Мы не можем использовать внешние сервисы, иначе мы бы использовали github или bitbucket. Усилия должны быть направлены на то, чтобы доработать то, как они хотят реализовать это в gitea, и не отвлекаться на дерьмовые альтернативы.

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

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

@ShalokShalom Я согласен, что ссылка была бы возможным первым шагом, может быть, даже просто для того, чтобы кого-то разозлить, чтобы сделать что-то лучше.

@strk конечно, но если нам просто нужна модульность, а не интеграция, зачем нам отслеживание проблем? релизы? ничего, кроме того, что дает gitosis

@lafriks Правда? Как?

@ptman Ну, чтобы интегрировать как ссылки на другие страницы, так и собственное решение - IS модульное?

@lukewatts Вас устраивает идея @strk ?

@ShalokShalom Я ожидаю, что ссылка исчезнет, ​​как только интегрированное решение станет доступным.

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

А во внутреннем решении будет отсутствовать важная для меня функциональность.

Подсветка синтаксиса находится в очень раннем состоянии.

Как это, чем о всплывающих подсказках ?

@ShalokShalom да, см. https://docs.gitea.io/en-us/customizing-gitea/ раздел «Добавление ссылок и вкладок» (это было добавлено в #3308)

Большое спасибо ^_^

@ShalokShalom До тех пор, пока ссылка на внешний сервис не станет поводом для того, чтобы поставить окончательное решение на длинный палец, я думаю, что пользовательская ссылка будет в порядке ..
Если бы я знал Го, я бы помог, а не просто скулил. Я за все, что приближает нас к хорошему окончательному решению в разумные сроки.

Вы также можете ссылаться на внутреннюю службу, если вы размещаете ее самостоятельно?

для меня подойдет что-то вроде GitHub gists, но если можно внести некоторые улучшения, например
теги/категории
или даже форматирование в стиле Medium/blog , что, очевидно, было бы плюсом

Я думаю, что интеграция в gitea без особых сложностей лучше всего подходит для философии giteas.

Безболезненный самостоятельный сервис Git.

Отмечая возможность децентрализации с помощью BitTorrent, IPFS или privEOS. Мне нравится владеть данными, но наличие чего-то более федеративного для этого было бы хорошим всплеском.

Таким образом, этому запросу уже более 2 лет. Интересно, есть ли в этом вообще какой-то прогресс?

Над этим никто не работает.

Поскольку теперь у нас есть поддержка oauth, мы можем создать что-то внешнее.

Да, я думаю, что образ @ShalokShalom прекрасен https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny Это Фларум.

Мне нравится идея удаленного пользователя .
И назвать их чашками, как предложил Ланни. ^^

Итак, раздали чашки. :сердце: - :сердце:
Разделите несколько чашек и давайте устроим чаепитие. :D

Для этой цели добавлены некоторые библиотеки (в Go):

Очень простое ядро: https://github.com/dyne/binnit
Довольно (&) завершено: https://github.com/andreimarcu/linx-server
Еще один: https://github.com/Parimer/spectre

И тот, что уже раздали:

Застопорилась в разработке, на основе IPFS: https://github.com/beardog108/seedbin

По предложению Ghost я нашел полностью децентрализованное (распределенное) решение для хостинга Git, и они могут быть заинтересованы в сотрудничестве. Я мог бы спросить их сегодня, если вы в порядке: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

Есть ли какие-либо обновления по этому поводу?
Из-за дополнительного обслуживания сторонние сервисы на моем рабочем месте недоступны, но сервис gitea cups нам бы пригодился.
Эта функция была бы огромным плюсом для меня :)

Я думаю, это должно быть в дорожной карте Gitea.

Да, пожалуйста, добавьте это!

Хотелось бы увидеть и это

Да, пожалуйста, добавьте это!

Хотелось бы увидеть и это

Пожалуйста, используйте эмоции для стартового комментария:

Это не будет беспокоить многих подписчиков по электронной почте:

И у него больше функций:

Мне очень нравится название Sips (по отношению к (gi)Tea) по сути. :) Кубки тоже хороши, но мне они напоминают полноразмерные репозитории.

У меня есть незаконченный PR, назовите его чашками

Общая система печати Unix? Прости :смеется:

@ Микаэла Ха! Даже не думал о таком использовании.

@lunny Я просмотрел PR, чтобы узнать, есть ли что-то, с чем я мог бы помочь или что-то позаимствовать, и я не нашел ничего, подходящего для pastebin, bin, paste, cup или cups? Я был бы рад помочь продвинуть его вперед, если уже что-то делается. Или даже если нет, если уж на то пошло. Просто не хочу дублировать усилия.

Arch использует PKGBUILD, в отличие от pkgbuild от Apple.
Чашки вместо CUPS должны быть в порядке. я не вижу борьбы

Какие-нибудь Новости?

Что касается имени

Если мы хотим, чтобы это было знакомо, это должно быть gists .

Если мы хотим, чтобы это было брендом, sips cups . Тем не менее, я бы возражал против брендинга такой общей функции.

Gitlab использует фирменные термины

В случае с Gitlab они выбрали «запрос на слияние» вместо «запрос на слияние», что имеет смысл, если учесть исторический контекст того, чем был «запрос на слияние» в исходном Github по сравнению с функциональностью «автоматического слияния», которую он впоследствии превратился в.

Тем не менее, я был бы удивлен, если бы они также не провели небольшое исследование Планировщика ключевых слов Google и не обнаружили, что использование термина «запрос на слияние» дало им какое-то преимущество в SEO.

Новый пользовательский опыт

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

Как новый пользователь, это заставит меня закатить глаза и подумать:

почему все должны называть одно и то же по-разному, тьфу

Последние мысли

gist НЕ является товарным знаком, это знакомо и имеет смысл

Если мы не будем использовать gist , чтобы быть знакомыми, я предлагаю выбрать имя специально с помощью Планировщика ключевых слов Google, чтобы обнаружить знакомые термины, которые люди ищут, когда они достигают «pastebin», «postbin», "суть" и др.

Я согласен с запросом на слияние, для меня это имеет гораздо больше смысла.

Мне лично нравится идея использовать собственное имя, и я искренне считаю, что для индекса Google достаточно просто указать это в документации следующим образом:

«Cups — это решение для сохранения заметок, похожее на то, что предоставляют GithubGist и Pastebin».

Почему брендинг важен

Собственные имена имеют смысл, поскольку они помогают идентифицировать - вот почему у всех нас разные имена.

Компании инвестируют около половины своего дохода в брендинг, заявление Pepsi «нам не нужно собственное имя, просто назовите его Cola» абсурдно.

Кроме того, давайте поговорим об уникальных функциях.

Просто мой жизненный опыт: когда вы говорите о GitHub, вы должны использовать PR (Pull Requests) (или Public Relations ?), когда вы говорите о GitLab — вы должны использовать MR (Merge Requests). А если кто-то не знаком, например, с GitLab, то это может быть так:

— Пожалуйста, откройте МР.
- Г-Н?
— Ага, типа… PR в GitHub.

А иногда, особенно если одно нравится больше другого, можно написать ошибку типа:

— Я открыл MR для вашего проекта на GitHub.
- Г-Н?
— Ой, простите, пиар.

То же самое о сниппетах и ​​гистах.

Вы можете называть вещи Gitea как хотите, но с новыми именами вы раздуете терминологию.

Почему не гитс? Легко сказать, это относится к gitea, но сейчас, когда я пишу.. вдруг... Будь проклят Бог.. Мне больше нравятся gitbits.. мало похожие на лакомые кусочки.
Хм.. хорошо, если бы появился такой плагин, это было бы мило! как бы это ни называлось. Кстати, спасибо за разработку gitea. Прекрасное программное обеспечение. Я также хотел бы, чтобы я мог редактировать файлы конфигурации своего сервера/серверов непосредственно в Gitea. С историей версий и всем остальным.

Лично мне все равно, как вы это называете. Я бы предпочел сначала сосредоточиться на реализации.

Сегодня я понял, что один сценарий не должен находиться в репозитории сценариев, которым я собирался поделиться, но я хотел получить этот сценарий так же, как я получаю другие сценарии с других компьютеров. Было бы глупо делать целое репо.

Это наводит меня на мысль, что приватные списки — это хороший способ хранить, извлекать и отслеживать секретные файлы.

Я назову имена, пока я здесь. Честно говоря, мне пока ничего не нравится. Я предлагаю назвать сервис Gistea, а фрагмент — Leaf. Gistea — это уникальное ключевое слово, но все же узнаваемое как суть Gitea, а листья — умная и привлекательная аналогия.

Я особенно не люблю "чашки". Напоминает мне одну сцену с Мардж Симпсон. "Кубок... ты можешь написать это?"

Я предлагаю назвать сервис Gistea, а фрагмент — Leaf.

мне нравится :innocent:

Я хотел бы иметь что-то вроде макета в этом комментарии . Всякий раз, когда я узнаю что-то новое, я всегда чувствую, что у меня нет подходящего места для размещения неформальной информации и заметок, особенно для вещей, которые не вписываются в конкретный проект.

Как реальный вариант использования, в последнее время я работаю над изучением Drone (CI). Поскольку это относится к любому проекту, мне негде документировать идеи, примеры, напоминания, советы и т. д. может быть отвлечением. Я мог бы сделать проект только для использования Вики, но Вики требует слишком формальной структуры для сбора случайных мыслей и идей.

Прямо сейчас я остановился на отдельном проекте, в котором я неправильно использую трекер проблем для неофициальных заметок только потому, что могу добавлять к ним ярлыки. В общем, я пытаюсь развивать документацию, используя issue --> wiki --> formal docs , но это не очень хорошо работает для мелких вещей, таких как советы Linux CLI и т. Д. Настройка, подобная той, что в связанном комментарии, где я мог классифицировать и помечать вещи было бы фантастически. Я бы использовал его тонну.

https://github.com/fragmenta/fragmenta-cms
Имеет биты postgresql golang.
MongoDB golang биты mysql, sylla/Cassandra.
Тем не менее, многочисленные сервисы pastebin,
(Файл конфигурации: gist, pastbin.., wetpaste и т. д.)

https://secrethub.io/ , немного лучше для ключей API или секретов, которые будут распространяться по ящикам, чем по сути.
Valt.io или аналогичные сервисы секретных хранилищ....

My.dev.box против взломанного.box.someplace.else
пароль юид, днс ок...
Если не в домашней локации или, например, на хостинг-сервере
убить.. это сейчас.
Можно одобрить коробки и списки для безопасности.

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

OSINT INTELLIGENCE, может разоблачить мои предполагаемые скрытые услуги. Т.е. суть..

Инструменты Python OSINT, ваш номерной знак, ваш адрес, мобильный телефон, оператор связи и т. д.
Github/gitlab/etc для ключей API, встроенных паролей....

Таким образом, фильтрация строк блоков, т.е. ключей API паролей
Также может оказаться РАЗУМНЫМ.

Одна альтернатива написана на ходу: https://dev.sigpipe.me/dashie/git.txt