:+1: untuk yang satu ini dan saya akan menyarankan untuk menamai fitur ini cup ,, seperti dalam cangkir teh....

@laplix Itu mungkin sedikit membingungkan dengan Common Unix Printing Service. Juga +1 juga.

cangkir? cupi? Atau cukup Pastebin?

Atau hanya cuplikan, saya tahu itu bukan nama yang mewah;)

Saya masih (lihat masalah gogs) berpikir ini harus menjadi layanan eksternal. Namun kita bisa membuatnya disuntikkan ke Gitea

Fitur pilihan:

) Bagian komentar
) Revisi (Riwayat)
) Penyorotan Sintaks, yang bahkan tidak tersedia di Gist
) Filter dan sortir

Banyak +1 dan banyak laporan masalah yang dibuat secara terpisah tentang proposal ini menunjukkan gambaran yang jelas:

gogit/gogs#936

di sisi lain, seharusnya cukup sederhana untuk mengimplementasikan snippet.

Simpan repo tersembunyi yang disebut _snippets (atau serupa), setiap cuplikan adalah folder, folder (atau cuplikan) dapat berisi banyak file. Selesai :)

@bkcsoft Di GitHub, setiap cuplikan adalah repo Git (tetapi dapat berisi banyak file). Tapi kita bisa membuatnya berbeda.

Saya tidak tahu apakah itu harus menjadi bagian dari Gitea atau proyek terpisah. Jika di Gitea, akan lebih mudah untuk menggunakan kembali kode.

Bagaimanapun kita harus ingat bahwa banyak orang (termasuk saya) tidak menyukai GitHub UI for Gists. Saya pikir kami bisa melakukannya dengan lebih baik. Harus ada kategori atau tag untuk mengatur intisari. Seharusnya mudah untuk menemukan dan mencari Intisari yang ada.

Berisi semua cuplikan dalam satu repo :

Kelebihan:

• Mudah untuk mengimpor / menyinkronkan dengan editor Anda
• Cukup mudah diimplementasikan :trollface: (pikirkan salin-tempel kode wiki)

Kontra:

• Mungkin lambat jika Anda sering menggunakan cuplikan
• Sulit untuk menghapus cuplikan sepenuhnya (menulis ulang riwayat, tidak pernah bagus)

Intisari UI memang payah... banyak yang harus diperbaiki, hanya terasa diretas bersama...

IMO kita harus memuat semua yang berkaitan dengan cuplikan ke repo tersebut (jika satu, kalau tidak, saya semua turun untuk submodul atau apa pun untuk melacaknya ...), ini termasuk kategori (folder siapa saja? :trollface:) dan tag

Memiliki itu sebagai file di repo memudahkan untuk menyinkronkannya ke editor Anda juga, dan membuatnya cukup mudah untuk melakukan pencarian

@andreynering Saya juga memikirkan tag, anggap ini ide yang bagus.
Mungkin letakkan tag/kategori ini di sisi kiri
Jadi mudah untuk membuat dan menemukan pastebins tertentu:

Mungkin menjadi kandidat yang baik untuk melakukan fork dan menyesuaikan: https://github.com/defunkt/Gist

Atau ini, https://github.com/gmarik/Gistie

defunkt/ Gist adalah alat baris perintah untuk berbicara dengan Gist, gmarik/Gistie ditulis dalam Ruby, keduanya tidak terlalu relevan di sini

Perpustakaan golang murni lebih disukai.

@lunny @bkcsoft dalam kasus saya, saya memposting Gistie menjadi opsi untuk melihat bagaimana alat ini bekerja dan diimplementasikan di Gitea, bukan untuk menggunakan alat di Gitea.

Anda dapat menggunakannya dengan server tergesa-gesa, sehingga orang tidak perlu memikirkan ruang. Gunakan hastebin.com secara default dan kirim permintaan dari klien menggunakan javascript, sehingga server tidak akan dibatasi kecepatannya. Tetapi juga memungkinkan pengguna untuk menggunakan server tergesa-gesa mereka sendiri. Itu bisa diimplementasikan menggunakan iframe.

Saya baru saja menemukan hari ini alat luar biasa yang ingin saya bagikan dengan Anda: fssnip.net

Ditambahkan ke bounty asli. Bagaimanapun, saya pikir memiliki setiap cuplikan sebagai reponya sendiri mungkin adalah cara terbaik untuk melakukannya sejauh sejarah dan modifikasi offline berjalan.

Omong-omong, tautan Bountysource tampaknya rusak. Berikut totalnya saat ini:

Beberapa ide tentang Gist atau kami menyebutnya Cups ?

1. Satu cup adalah repositori tertentu, sehingga kami dapat menggunakan kembali semua kode lama. Kemudian kami memiliki jenis repositori mirrored, fork, cups, dan lain-lain.
2. Setiap jenis repositori dapat memiliki tab yang berbeda (kami menyimpannya di repo_unit). Jadi setiap repositori dapat memuat unit mereka ke tab.
3. Untuk cup repositori, hanya ada file teks yang diperbolehkan (tidak ada folder, tidak ada gambar, tidak ada file biner) dan nama file pertama juga nama repositori. Misalnya tea.go . UI utama repositori cup akan menampilkan kode file dan beberapa komentar. Komentar bisa di bagian bawah atau di beberapa baris kode.
   Juga memiliki deskripsi atau mungkin kelas.
4. Untuk repositori cup , hanya ada satu masalah saat membuat repositori. Semua komentar harus mengikuti masalah ini, maka kita dapat melihat semua komentar di UI cup .
5. cup repositori bisa di /cups/<user_name>/<cup_name> dan entri terpisah di menu atas dasbor. Semua tempat lain tidak akan menampilkan repositori jenis ini. Tetapi nama repositori tidak dapat digunakan kembali pada repositori normal pengguna. UI ini bisa berupa tangkapan layar @ShalokShalom atau ide baru apa pun. dan menyediakan pencarian kode karena kami telah menggabungkannya di v1.3.

Lihatlah Gists, mungkin ada beberapa file.

@lunny Sehubungan dengan 3: dengan intisari saya terkadang menggunakan banyak file jadi saya pikir membatasinya pada satu file mungkin tidak berfungsi untuk beberapa kasus. Juga, mungkin alih-alih menerapkan ekstensi file, kami dapat mengasumsikan teks/polos, atau memeriksa apakah file tersebut adalah file biner dan kemudian hanya memberikan tautan ke file mentah.

Sunting: ptman melakukannya terlebih dahulu.

File biner untuk layanan pastebin? Bukan ide yang bagus.

Harap tidak memerlukan ekstensi file, jika tidak, Anda tidak akan dapat membagikan makefile.

@ptman @tboerger @techknowlogick memperbarui komentar saya.

Karena beberapa orang tidak menyukai bagaimana kami mengintegrasikan pelacakan waktu ke dalam inti, bagaimana dengan menjadikan pastebins sebagai layanan eksternal yang terintegrasi erat dengan giteas api dan menggunakan repositorinya untuk menyimpan pasta?
Saya pikir bahkan Githubs pastebin adalah jenis layanan eksternal ...

@kolaente jadi default dinonaktifkan. Tetapi sebagai layanan eksternal, itu akan membutuhkan lebih banyak pekerjaan daripada sebagai layanan internal karena repositori, masalah, komentar semuanya sudah siap.

Keduanya? Jadi Github Gists bersama dengan solusi sendiri?
Dan Gitpin(s) untuk nama internal?

Pemilik EDIT: Harap jaga agar diskusi tetap aman untuk bekerja ...

+1

@lunny Bagaimana dengan ini. Pesan repositori _snippets.git lalu minta layanan eksternal menggunakannya untuk cuplikan?

Sunting: Dengan begitu kami masih memiliki akses ke komentar (setelah diimplementasikan dan digabungkan :trollface: )

Atau .snippets.git seperti .wiki.git ? Dan layanan eksternal mana yang cocok untuk melakukan itu?

Saya pikir jika kami memiliki layanan eksternal yang menangani layanan pastebin, kami tidak perlu memesan repositori untuk ini.

Jika tidak, jika kami menerapkan layanan pastebin di gitea, saya akan menyukai gagasan tentang repositori yang dicadangkan, karena pasta biasanya tidak terlalu banyak, saya tidak melihat kebutuhan untuk membuat repositori setiap saat, saya pikir ini akan menjadi terlalu banyak repositori setelah beberapa waktu ketika membuat beberapa pasta.

Saya pikir repositori tunggal dapat digunakan dan cabang baru untuk setiap tempel

Adakah alasan mengapa kita tidak boleh memiliki repo per tempel? Salah satu hal paling keren tentang GitHub's Gists adalah bahwa mereka sebenarnya adalah repo lengkap yang dapat dikloning dan dikomit.

Saya melihatnya juga begitu, 54

+1

Setelah memungkinkan: Bisakah kita membuat tombol yang menautkan ke layanan pastebin khusus?

Ini memberi kami beberapa keuntungan: Pengembangan dan penyesuaian yang sangat cepat.
Sejujurnya:
Sejak saya menulis masalah ini, apakah bahasa pilihan saya berubah dan layanan pastebin-nya mendukung bahkan tooltips dan perpustakaan.

Implementasi Gitea masih dimungkinkan nanti dan ini (sebaik) tidak ada upaya tambahan?

Saya tidak mendukung layanan pastebin eksternal. Alasan perusahaan saya menggunakan Gitea adalah untuk memilikinya di dalam jaringan internal karena untuk keamanan dan akses internal. Kami tidak dapat menggunakan layanan eksternal jika tidak, kami akan menggunakan github atau bitbucket. Upaya harus dilakukan untuk menyelesaikan bagaimana mereka ingin menerapkannya di gitea dan tidak terganggu dengan alternatif omong kosong

Pokoknya dalam versi master Anda dapat menambahkan tab khusus ke tautan eksternal di templat khusus Anda

"eksternal" tidak selalu berarti "dijalankan oleh orang lain"
modularitas memiliki kelebihan juga ...

@ShalokShalom Saya setuju bahwa tautan akan menjadi langkah pertama yang mungkin, bahkan mungkin hanya cukup mengganggu seseorang untuk membuat sesuatu yang lebih baik

@strk tentu, tetapi jika kami hanya ingin modularitas, dan tidak ada integrasi, mengapa kami memiliki masalah pelacakan? rilis? apa pun selain yang disediakan gitosis

@lafriks Benarkah? Bagaimana?

@ptman Nah, untuk mengintegrasikan keduanya - tautan ke halaman lain dan solusi sendiri - IS modular?

@lukewatts Apakah ide @strk baik untuk Anda?

@ShalokShalom Saya berharap tautannya hilang begitu solusi terintegrasi tersedia

Tautan untuk tindakan umum sangat membantu. Anda dapat menautkan ke halaman proyek Anda dan sebagainya.

Dan solusi internal akan kekurangan fungsionalitas yang penting bagi saya.

Penyorotan sintaksis dalam keadaan sangat awal.

Bagaimana itu daripada tentang Tooltips ?

@ShalokShalom ya, lihat https://docs.gitea.io/en-us/customizing-gitea/ bagian "Menambahkan tautan dan tab" (ini ditambahkan di #3308)

Terima kasih banyak ^_^

@ShalokShalom Selama tautan ke layanan eksternal tidak menjadi alasan untuk meletakkan solusi akhir di jari yang panjang, saya kira tautan khusus akan baik-baik saja ..
Jika saya tahu Go, saya akan membantu daripada hanya mengomel. Saya mendukung apa pun yang membuat kita lebih dekat ke solusi akhir yang baik dalam waktu yang wajar.

Anda dapat menautkan ke layanan internal juga, selama Anda menghostingnya sendiri?

bagi saya apa pun seperti GitHub Gists akan dilakukan tetapi jika beberapa perbaikan dapat dilakukan seperti
tag/kategori
atau bahkan pemformatan gaya Medium/blog yang jelas akan menjadi nilai tambah

Saya pikir integrasi ke gitea tanpa banyak komplikasi adalah yang terbaik untuk filosofi giteas

Layanan Git yang dihosting sendiri tanpa rasa sakit.

Memperhatikan peluang untuk melakukan desentralisasi menggunakan BitTorrent, IPFS atau privEOS. Saya suka memiliki data, tetapi memiliki sesuatu yang lebih terpadu untuk ini akan menjadi lonjakan yang bagus untuk dilihat.

Jadi permintaan ini sekarang sudah lebih dari 2 tahun. Saya bertanya-tanya apakah ada kemajuan dalam hal ini?

Tidak ada yang mengerjakan ini.

Karena kami sekarang memiliki dukungan oauth, kami mungkin dapat membangun beberapa hal eksternal.

Ya, menurut saya gambar @ShalokShalom itu indah https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny Ini Flarum.

Saya suka ide pengguna yang dihapus .
Dan menamai mereka cangkir juga, seperti yang diusulkan lunny. ^^

Jadi dibagikan cangkir. :hati: - :hati:
Bagikan beberapa cangkir dan mari kita buat pesta teh. :D

Melempar beberapa perpustakaan (di Go) untuk tujuan itu:

Inti yang sangat sederhana: https://github.com/dyne/binnit
Cukup (&) lengkap: https://github.com/andreimarcu/linx-server
Satu lagi: https://github.com/Parimer/spectre

Dan yang sudah didistribusikan:

Terhenti dalam pengembangan, berbasis IPFS: https://github.com/beardog108/seedbin

Menurut saran Ghost, saya menemukan solusi hosting Git yang sepenuhnya terdesentralisasi (terdistribusi) dan mereka mungkin tertarik untuk bekerja sama. Saya mungkin bertanya kepada mereka hari ini, jika Anda baik-baik saja: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

Apakah ada pembaruan tentang ini?
Pemeliharaan tambahan membuat layanan eksternal tidak dapat digunakan di tempat kerja saya, tetapi layanan cangkir gitea akan berguna bagi kami.
Fitur ini akan menjadi nilai tambah yang besar bagi saya :)

Saya pikir ini harus ada di peta jalan Gitea.

Ya, tolong tambahkan ini!

Akan senang melihat ini juga

Ya, tolong tambahkan ini!

Akan senang melihat ini juga

Tolong, gunakan emosi untuk komentar pembuka masalah:

Itu tidak akan mengganggu banyak orang yang berlangganan melalui email:

Dan itu memiliki lebih banyak fungsi:

Saya cukup menyukai nama Sips (dalam kaitannya dengan (gi)Tea) untuk intinya. :) Cangkir juga bagus, tetapi mengingatkan saya pada repositori berukuran penuh.

Saya memiliki PR yang belum selesai, beri nama cangkir

Sistem Pencetakan Unix Umum? maaf :ketawa:

@Mikaela Hah! Bahkan tidak memikirkan penggunaan itu.

@lunny Saya melihat-lihat PR untuk melihat apakah ada sesuatu yang bisa saya bantu atau hilangkan dan saya tidak melihat sesuatu yang cocok dengan pastebin, bin, paste, cup, atau cup? Saya akan dengan senang hati membantu memajukannya jika sudah ada sesuatu yang sedang berjalan. Atau bahkan jika tidak ada, dalam hal ini. Hanya tidak ingin menduplikasi usaha.

Arch menggunakan PKGBUILDs, berlawanan dengan pkgbuild dari Apple.
Cangkir bukannya CUPS seharusnya baik-baik saja. Saya tidak melihat perjuangan

Ada berita?

Adapun Nama

Jika kita ingin familiar, seharusnya gists .

Jika kita ingin menjadi brandable, sips lebih masuk akal daripada cups bagi saya. Namun, saya menentang branding fitur generik seperti itu.

Gitlab menggunakan istilah bermerek

Dalam kasus Gitlab, mereka memilih "permintaan penggabungan" alih-alih "permintaan tarik", yang masuk akal jika Anda mempertimbangkan konteks historis dari "Permintaan Tarik" pada Github asli vs fungsi "penggabungan otomatis" yang kemudian berkembang menjadi.

Namun, saya akan terkejut jika mereka juga tidak melakukan sedikit riset Google Keyword Planner dan menemukan bahwa menggunakan istilah "Merge Request" memberi mereka semacam keuntungan SEO.

Pengalaman Pengguna Baru

Seperti yang saya katakan, saya pribadi tidak melihat banyak nilai dalam memberinya nama bermerek.

Sebagai pengguna baru, itu akan menjadi hal yang membuat saya memutar mata dan berpikir:

kenapa setiap orang harus memanggil hal yang sama dengan nama yang berbeda, ugh

Pikiran Akhir

gist BUKAN merek dagang, itu familiar, dan masuk akal

Jika kita tidak menggunakan gist untuk menjadi familiar, saya sarankan kita memilih nama dengan sengaja menggunakan Google Keyword Planner untuk menemukan istilah familiar yang dicari orang ketika mereka tiba di "pastebin", "postbin", "inti", dll.

Saya setuju dengan permintaan penggabungan, lebih masuk akal bagi saya.

Saya pribadi menyukai ide untuk menggunakan nama sendiri dan sejujurnya saya pikir, untuk indeks google cukup dengan menuliskannya di dokumentasi sebagai berikut:

"Cup adalah solusi untuk menyimpan catatan dan mirip dengan yang disediakan GithubGist dan Pastebin."

Mengapa merek itu penting

Nama sendiri masuk akal karena membantu mengidentifikasi - itulah mengapa kita semua tidak memiliki nama yang sama.

Perusahaan menginvestasikan sekitar _setengah dari pendapatan mereka_ ke dalam branding, Pepsi mengatakan "kita tidak perlu nama sendiri, sebut saja Cola" tidak masuk akal.

Juga, mari kita bicara tentang fitur unik.

Hanya pengalaman hidup saya: ketika Anda berbicara tentang GitHub, Anda harus menggunakan PR (Pull Requests) (atau Public Relations ?), ketika Anda berbicara tentang GitLab — Anda harus menggunakan MR (Merge Requests). Dan jika seseorang tidak akrab dengan GitLab, misalnya, bisa seperti:

— Tolong, buka MR.
- PAK?
— Ya, seperti… PR di GitHub.

Dan terkadang, terutama jika Anda lebih menyukai satu dari yang lain, Anda dapat menulis kesalahan seperti:

— Saya telah membuka MR untuk proyek GitHub Anda.
- PAK?
- Oh, maaf, PR.

Hal yang sama tentang cuplikan vs inti.

Anda dapat memanggil hal-hal Gitea seperti yang Anda inginkan, tetapi dengan nama baru Anda akan mengasapi terminologi.

Mengapa tidak git? Mudah untuk mengatakan, itu mengacu pada gitea, tetapi sekarang ketika saya menulis.. tiba-tiba... Tuhan.. Saya lebih suka gitbits.. sedikit seperti berita gembira.
Hmm.. nah kalau ada plugin seperti itu pasti manis! apapun namanya. Terima kasih telah mengembangkan gitea. Perangkat lunak yang indah. Saya juga menginginkan fitur ketika saya dapat mengedit file konfigurasi server/server saya langsung di Gitea. Dengan riwayat versi dan segalanya.

Secara pribadi, saya tidak peduli Anda menyebutnya apa. Saya lebih suka melihat fokus pada implementasi terlebih dahulu.

Hari ini saya menyadari satu skrip tidak boleh berada dalam repo skrip yang akan saya bagikan, tetapi saya ingin mengambil skrip itu dengan cara yang sama seperti saya mengambil skrip lain dari mesin lain. Akan konyol untuk membuat seluruh repo.

Itu membuat saya berpikir intisari pribadi adalah cara yang baik untuk menyimpan, mengambil, dan melacak file rahasia.

Saya akan menyebutkan nama saat saya di sini. Terus terang saya tidak suka sejauh ini. Saya sarankan menamai layanan Gistea dan cuplikannya dengan Leaf. Gistea adalah kata kunci unik yang masih dapat dikenali sebagai intisari Gitea, dan daun adalah analogi yang cerdas dan menarik.

Saya terutama tidak suka "cangkir". Mengingatkan saya pada adegan Marge Simpson tertentu. "Cup... bisakah kamu mengeja itu?"

Saya sarankan menamai layanan Gistea dan cuplikannya dengan Leaf.

Saya suka itu :innocent:

Saya ingin memiliki sesuatu seperti mockup di komentar ini . Setiap kali saya mempelajari sesuatu yang baru, saya selalu merasa bahwa saya tidak memiliki tempat yang baik untuk menaruh informasi dan catatan informal, terutama untuk hal-hal yang tidak sesuai dengan proyek tertentu.

Sebagai kasus penggunaan yang sebenarnya, saya telah mempelajari Drone (CI) akhir-akhir ini. Karena ini berlaku untuk proyek apa pun, tidak ada tempat yang bagus bagi saya untuk mendokumentasikan ide, contoh, pengingat, tip, dll. Saya tidak cukup tahu untuk memulai situs dokumentasi untuk pedoman saya sendiri dan, bahkan jika saya melakukannya, saya menemukan itu bisa menjadi pengalih perhatian. Saya bisa membuat proyek hanya untuk menggunakan Wiki, tetapi Wiki membutuhkan struktur yang terlalu formal untuk mengumpulkan banyak pemikiran dan ide acak.

Saat ini saya telah menyelesaikan proyek terpisah di mana saya menyalahgunakan pelacak masalah untuk catatan informal hanya karena saya dapat menambahkan label ke dalamnya. Secara umum saya mencoba mengembangkan dokumentasi dengan menggunakan issue --> wiki --> formal docs , tetapi itu tidak berfungsi dengan baik untuk hal-hal kecil seperti tip Linux CLI, dll. Pengaturan seperti yang ada di komentar tertaut di mana saya dapat mengkategorikan dan menandai sesuatu akan menjadi fantastis. Saya akan menggunakannya satu ton.

https://github.com/fragmenta/fragmenta-cms
Memiliki bit golang postgresql.
Mongodb golang bit mysql, sylla/Cassandra.
Namun mereka, banyak Layanan pastebin,
( File konfigurasi: Gist, pastbin.. , wetpaste, dll)

https://secrethub.io/ , sedikit lebih baik untuk kunci api atau rahasia untuk didistribusikan ke kotak daripada inti.
Valt.io atau layanan kubah rahasia serupa....

My.dev.box , vs hacked.box.someplace.else
Kata sandi uid, dns ok ...
Jika tidak di lokasi rumah atau server hosting
bunuh.. sekarang.
Dapat menyetujui kotak vs intisari untuk Keamanan.

Saya benar-benar ingin private Gist api saya flipping key private...
Memiliki beberapa coretan di blog pengembang tim secara tidak sengaja ...

OSINT INTELLIGENCE, dapat membuka kedok layanan tersembunyi saya. Yaitu intinya..

Alat Python OSINT , plat nomor Anda, alamat Anda, ponsel, operator, dll.
Github/gitlab/etc untuk kunci api , kata sandi yang disematkan ....

Jadi memfilter string blok yaitu kata sandi kunci api
Mungkin juga membuktikan SANE.

Satu alternatif ditulis di go: https://dev.sigpipe.me/dashie/git.txt