:+1: इसके लिए और मैं इस फीचर कप को नाम देने का सुझाव दूंगा, जैसे कि चाय के प्यालों में....

@laplix यह सामान्य यूनिक्स मुद्रण सेवा के साथ थोड़ा भ्रमित करने वाला हो सकता है। साथ ही +1 भी करें।

प्याला? क्यूपी? या बस पास्टबिन?

या सिर्फ स्निपेट्स, मुझे पता है कि यह एक फैंसी नाम नहीं है;)

मैं अभी भी (गॉग्स इश्यू देखें) सोचता हूं कि यह एक बाहरी सेवा होनी चाहिए। हालाँकि हम इसे गीता में इंजेक्ट करने योग्य बना सकते हैं

वैकल्पिक विशेषताएं:

) टिप्पणी अनुभाग
) संशोधन (इतिहास)
) सिंटैक्स हाइलाइटिंग, जो Gist . में भी उपलब्ध नहीं है
) फ़िल्टर और छँटाई

इस प्रस्ताव के बारे में बहुत सी +1 और कई अलग-अलग बनाई गई समस्या रिपोर्ट एक स्पष्ट तस्वीर दिखाती हैं:

गोगिट/गोग#936

दूसरी ओर, स्निपेट्स को लागू करना काफी सरल होना चाहिए।

_snippets (या समान) नामक एक छिपा हुआ रेपो रखें, प्रत्येक स्निपेट एक फ़ोल्डर है, एक फ़ोल्डर (या स्निपेट) में कई फ़ाइलें हो सकती हैं। पूर्ण :)

गिटहब पर @bkcsoft, प्रत्येक स्निपेट एक गिट रेपो है (लेकिन इसमें कई फाइलें हो सकती हैं)। लेकिन हम इसे अलग बना सकते हैं।

मुझे नहीं पता कि यह गीता का हिस्सा होना चाहिए या किसी अलग परियोजना का। यदि गीता में, कोड का पुन: उपयोग करना आसान होगा।

वैसे भी हमें यह ध्यान रखना चाहिए कि बहुत से लोग (मुझे शामिल) Gist के लिए GitHub UI को नापसंद करते हैं। मुझे लगता है कि हम इसे बेहतर कर सकते हैं। सार को व्यवस्थित करने के लिए श्रेणियां या टैग होने चाहिए। मौजूदा सार को खोजना और खोजना आसान होना चाहिए।

एक रेपो में सभी स्निपेट्स से युक्त:

पेशेवरों:

• अपने संपादक के साथ आयात/सिंक करना आसान
• लागू करने में काफी आसान: ट्रोलफेस: (सोचें कॉपी-पेस्ट विकी-कोड)

दोष:

• यदि आप स्निपेट का बहुत अधिक उपयोग करते हैं तो धीमा हो सकता है
• एक स्निपेट को पूरी तरह से निकालना मुश्किल है (इतिहास फिर से लिखें, कभी अच्छा नहीं)

जिस्ट यूआई वास्तव में बेकार है ... सुधार करने के लिए बहुत कुछ है, बस एक साथ हैक किया गया लगता है ...

आईएमओ हमें स्निपेट्स से संबंधित रेपो के बारे में सब कुछ शामिल करना चाहिए (यदि एक एकल, अन्यथा मैं सबमॉड्यूल के लिए नीचे हूं या जो कुछ भी उनका ट्रैक रखना है ...), इसमें श्रेणियां शामिल हैं (फ़ोल्डर कोई भी?: ट्रोलफेस :) और टैग

रेपो में एक फ़ाइल के रूप में होने से इसे आपके संपादक के साथ भी सिंक करना आसान हो जाता है, और खोजों को करना काफी आसान हो जाता है

@andreynering मैंने टैग के बारे में भी सोचा, यह एक अच्छा विचार है।
शायद इन टैग/श्रेणियों को बाईं ओर रखें
तो विशिष्ट पेस्टबिन बनाना और ढूंढना आसान है:

कांटा और समायोजन के लिए एक अच्छा उम्मीदवार हो सकता है: https://github.com/defunkt/gist

या यह, https://github.com/gmarik/Gistie

defunkt/gist जिस्ट से बात करने के लिए एक कमांड लाइन टूल है, gmarik/Gistie रूबी में लिखा गया है, दोनों यहां बहुत प्रासंगिक नहीं हैं

एक शुद्ध गोलांग पुस्तकालय को प्राथमिकता दी जाती है।

@lunny @bkcsoft मेरे मामले में, मैं गिस्टी को यह देखने के लिए एक विकल्प के रूप में पोस्ट करता हूं कि यह उपकरण कैसे काम करता है और गीता पर लागू होता है, न कि गीता में एक उपकरण का उपयोग करने के लिए।

आप इसे जल्दबाजी में सर्वर के साथ इस्तेमाल कर सकते हैं, इसलिए लोगों को जगह के बारे में सोचने की जरूरत नहीं है। डिफ़ॉल्ट रूप से hastebin.com का उपयोग करें और जावास्क्रिप्ट का उपयोग करके क्लाइंट से अनुरोध भेजें, इसलिए सर्वर दर-सीमित नहीं होगा। लेकिन उपयोगकर्ताओं को अपने स्वयं के जल्दबाजी-सर्वर का उपयोग करने की अनुमति भी दें। इसे एक आईफ्रेम का उपयोग करके कार्यान्वित किया जा सकता है।

मुझे आज ही एक शानदार टूल मिला है जिसे मैं आपके साथ साझा करना चाहता हूं: fssnip.net

मूल इनाम में जोड़ा गया। वैसे भी, मुझे लगता है कि प्रत्येक स्निपेट को अपने स्वयं के रेपो के रूप में इतिहास और ऑफ़लाइन संशोधन के रूप में इसे करने का सबसे अच्छा तरीका है।

वैसे, बाउंटीसोर्स लिंक टूटा हुआ प्रतीत होता है। यहाँ वर्तमान कुल है:

Gist के बारे में कुछ विचार या हम इसे Cups कहते हैं?

1. एक cup एक निर्दिष्ट भंडार है, ताकि हम सभी पुराने कोड का पुन: उपयोग कर सकें। फिर हमारे पास मिरर, फोर्क, कप और आदि भंडार प्रकार हैं।
2. प्रत्येक प्रकार के भंडार में अलग-अलग टैब हो सकते हैं (हम उन्हें repo_unit पर संग्रहीत करते हैं)। तो प्रत्येक भंडार अपनी इकाइयों को टैब पर लोड कर सकता है।
3. cup रिपॉजिटरी के लिए, केवल पाठ फ़ाइलों की अनुमति है (कोई फ़ोल्डर नहीं, कोई चित्र नहीं, कोई बाइनरी फ़ाइल नहीं) और पहली फ़ाइल का नाम भी रिपॉजिटरी का नाम है। उदाहरण के लिए tea.go । cup रिपोजिटरी मुख्य UI फ़ाइल का कोड और कुछ टिप्पणियां दिखाएगा। टिप्पणी नीचे या किसी कोड लाइन पर हो सकती है।
   इसके अलावा इसमें विवरण या शायद कक्षाएं भी हैं।
4. cup रिपॉजिटरी के लिए, रिपॉजिटरी बनाते समय केवल एक ही समस्या होती है। सभी टिप्पणियों को इस मुद्दे का पालन करना चाहिए, फिर हम cup UI पर सभी टिप्पणियों को देख सकते हैं।
5. cup भंडार /cups/<user_name>/<cup_name> में हो सकते हैं और डैशबोर्ड शीर्ष मेनू पर एक अलग प्रविष्टि हो सकती है। अन्य सभी स्थान इस प्रकार के भंडार नहीं दिखाएंगे। लेकिन उपयोगकर्ता के सामान्य भंडार पर भंडार नाम का पुन: उपयोग नहीं किया जा सका। यह UI @ShalokShalom के स्क्रीनशॉट या कोई नया विचार हो सकता है। और कोड खोज प्रदान करें क्योंकि हमने इसे v1.3 पर मर्ज कर दिया है।

सार पर एक नज़र डालें, कई फाइलें हो सकती हैं।

@lunny 3 के संबंध में: जिस्ट के साथ मैं कभी-कभी कई फाइलों का उपयोग करता हूं, इसलिए मुझे लगता है कि इसे सीमित करना कुछ मामलों के लिए काम नहीं कर सकता है। साथ ही, शायद फ़ाइल एक्सटेंशन को लागू करने के बजाय हम या तो टेक्स्ट/सादा मान सकते हैं, या जांच सकते हैं कि फ़ाइल बाइनरी फ़ाइल है या नहीं और फिर कच्ची फ़ाइल के लिए एक लिंक प्रदान करें।

संपादित करें: पीटीमैन इसे पहले मिला।

एक पास्टबिन सेवा के लिए बाइनरी फ़ाइलें? अच्छा विचार नहीं।

कृपया फ़ाइल एक्सटेंशन की आवश्यकता नहीं है, अन्यथा आप मेकफ़ाइल साझा नहीं कर पाएंगे।

@ptman @tboerger @techknowlogic ने मेरी टिप्पणियों को अपडेट किया।

जैसा कि कुछ लोगों को यह पसंद नहीं आया कि हम कोर में टाइमट्रैकिंग को कैसे एकीकृत करते हैं, पेस्टबिन को एक बाहरी सेवा बनाने के बारे में क्या है जो गिटास एपीआई के साथ कसकर एकीकृत करता है और पेस्ट को स्टोर करने के लिए इसके भंडार का उपयोग करता है?
मुझे लगता है कि जीथब पेस्टबिन भी एक बाहरी सेवा है ...

@kolaente इसलिए डिफ़ॉल्ट अक्षम है। लेकिन एक बाहरी सेवा के रूप में, इसे आंतरिक की तुलना में अधिक काम करने की आवश्यकता होगी क्योंकि रिपॉजिटरी, इश्यू, कमेंट सभी तैयार हैं।

दोनों? तो Github Gists एक साथ अपने समाधान के साथ?
और आंतरिक नाम के लिए गिटपिन?

स्वामी संपादित करें: कृपया चर्चाओं को कार्य के लिए सुरक्षित रखें...

+1

@luny इसके बारे में कैसे। भंडार _snippets.git आरक्षित करें और फिर बाहरी सेवा का उपयोग स्निपेट के लिए करें?

संपादित करें: इस तरह हमारे पास अभी भी टिप्पणियों तक पहुंच है (एक बार इसे लागू और विलय कर दिया गया है: ट्रोलफेस:)

या .snippets.git जैसे .wiki.git ? और ऐसा करने के लिए कौन सी बाहरी सेवा उपयुक्त है?

मुझे लगता है कि अगर हमारे पास एक बाहरी सेवा है जो पेस्टबिन सेवा को संभालती है तो हमें इसके लिए एक भंडार आरक्षित करने की आवश्यकता नहीं होगी।

अन्यथा, अगर हम गिटिया में पेस्टबिन सेवा लागू करते हैं तो मुझे एक आरक्षित भंडार के विचार से प्यार होगा, क्योंकि पेस्ट आमतौर पर बहुत ज्यादा नहीं होता है, मुझे हर बार एक भंडार बनाने की आवश्यकता नहीं दिखती है, मुझे लगता है कि यह होगा कुछ पेस्ट बनाते समय कुछ समय बाद बहुत अधिक भंडार।

मुझे लगता है कि एकल भंडार का उपयोग किया जा सकता है और प्रत्येक पेस्ट के लिए नई शाखा का उपयोग किया जा सकता है

किसी भी कारण से हमारे पास प्रति पेस्ट रेपो नहीं होना चाहिए? गिटहब के जिस्ट के बारे में सबसे अच्छी चीजों में से एक यह है कि वे वास्तव में पूर्ण रेपो हैं जिन्हें क्लोन और प्रतिबद्ध किया जा सकता है।

मैं इसे भी देखता हूं, 54

+1

एक बार संभव होने पर: क्या हम केवल एक बटन बना सकते हैं जो एक कस्टम पेस्टबिन सेवा से जुड़ता है?

यह हमें कई फायदे देता है: बहुत तेज विकास और अनुकूलन।
ईमानदार रहना:
चूंकि मैंने इस मुद्दे को लिखा है, मेरी पसंदीदा भाषा बदल गई है और इसकी पेस्टबिन सेवा टूलटिप्स और पुस्तकालयों का भी समर्थन करती है।

एक गीता कार्यान्वयन अभी भी बाद में संभव है और यह (इतना अच्छा) शून्य अतिरिक्त प्रयास है?

मैं बाहरी पास्टबिन सेवा के पक्ष में नहीं हूं। मेरी कंपनी द्वारा गीता का उपयोग करने का कारण सुरक्षा और आंतरिक पहुंच के लिए इसे आंतरिक नेटवर्क के अंदर रखना है। हम बाहरी सेवाओं का उपयोग नहीं कर सकते हैं अन्यथा हम जीथब या बिटबकेट का उपयोग कर रहे होंगे। इसे अंतिम रूप देने का प्रयास किया जाना चाहिए कि वे इसे गीता में कैसे लागू करना चाहते हैं और बकवास विकल्पों से विचलित नहीं होना चाहिए

वैसे भी मास्टर संस्करण में आप अपने कस्टम टेम्पलेट में बाहरी लिंक में कस्टम टैब जोड़ सकते हैं

"बाहरी" का अर्थ अनिवार्य रूप से "किसी और द्वारा चलाया गया" नहीं है
मॉड्यूलरिटी के अपने फायदे भी हैं ...

@ शालोक शालोम मैं मानता हूं कि एक लिंक एक संभावित पहला कदम होगा, शायद किसी को कुछ बेहतर बनाने के लिए परेशान करने के लिए भी

@strk यकीन है, लेकिन अगर हम सिर्फ प्रतिरूपकता चाहते हैं, और कोई एकीकरण नहीं है, तो हमारे पास ट्रैकिंग जारी क्यों है? रिलीज? गिटोसिस क्या प्रदान करता है इसके अलावा कुछ भी

@lafriks सच में? कैसे?

@ptman ठीक है, दोनों को एकीकृत करने के लिए - अन्य पृष्ठों के लिंक और स्वयं के समाधान - मॉड्यूलर है ?

@lukewatts क्या @strk का विचार आपके लिए ठीक है?

@शालोकशालोम मैं उम्मीद करता हूं कि एक एकीकृत समाधान उपलब्ध होने के बाद लिंक दूर हो जाएगा

सामान्य क्रियाओं के लिए लिंक वैसे भी मददगार है। आप अपने प्रोजेक्ट पेज वगैरह से लिंक कर सकते हैं।

और आंतरिक समाधान में कार्यक्षमता की कमी होगी जो मेरे लिए महत्वपूर्ण है।

सिंटैक्स हाइलाइटिंग बहुत प्रारंभिक अवस्था में है।

टूलटिप्स के बारे में यह कैसा है?

@ShalokShalom हाँ, देखें https://docs.gitea.io/en-us/customizing-gitea/ अनुभाग "लिंक और टैब जोड़ना" (इसे #3308 में जोड़ा गया था)

बहुत बहुत धन्यवाद ^_^

@ShalokShalom जब तक किसी बाहरी सेवा का लिंक लंबी उंगली पर अंतिम समाधान डालने का बहाना नहीं बनता, मुझे लगता है कि एक कस्टम लिंक ठीक रहेगा ..
अगर मैं गो को जानता तो मैं सिर्फ कुतर्क करने के बजाय मदद करता। मैं किसी भी चीज के पक्ष में हूं जो हमें उचित समय में एक अच्छे अंतिम समाधान के करीब ले जाती है।

आप किसी आंतरिक सेवा से भी लिंक कर सकते हैं, जब तक कि आप इसे स्वयं होस्ट करते हैं?

मेरे लिए गिटहब जिस्ट जैसा कुछ भी करेगा लेकिन अगर कुछ सुधार किए जा सकते हैं जैसे
टैग/श्रेणियां
या यहां तक ​​कि मध्यम/ब्लॉग शैली स्वरूपण जो स्पष्ट रूप से एक प्लस होगा

मुझे लगता है कि बिना किसी जटिलता के गीता में एकीकरण गीता दर्शन के लिए सर्वोत्तम है

एक दर्द रहित स्व-होस्टेड गिट सेवा।

बिटटोरेंट, आईपीएफएस या प्राइवेटईओएस का उपयोग करके विकेंद्रीकरण करने का अवसर। मुझे डेटा का स्वामित्व पसंद है, लेकिन इसके लिए कुछ और फ़ेडरेटेड होना देखने के लिए एक अच्छा स्पाइक होगा।

इसलिए यह अनुरोध अब 2 वर्ष से अधिक पुराना है। मुझे आश्चर्य है कि क्या इस पर कोई प्रगति हुई है?

इस पर कोई काम नहीं कर रहा है।

चूंकि अब हमारे पास शपथ समर्थन है, इसलिए हम कुछ बाहरी चीजों का निर्माण करने में सक्षम हो सकते हैं।

हाँ, मुझे लगता है @ShalokShalom की छवि सुंदर है https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@ लुनी यह फ्लारम है ।

मुझे हटाए गए उपयोगकर्ता का विचार पसंद है।
और उनका नाम भी कप रखना, जैसे लूनी ने प्रस्तावित किया। ^^

ऐसे में कप बांटे। :दिल दिल:
कुछ कप बांटो और चलो एक चाय पार्टी करते हैं। :डी

उस उद्देश्य के लिए कुछ पुस्तकालयों (गो में) में फेंकना:

बहुत ही सरल कोर: https://github.com/dyne/binnit
सुंदर (&) पूर्ण: https://github.com/andreimarcu/linx-server
एक और: https://github.com/Parimer/spectre

और एक जो पहले ही वितरित हो चुका है:

विकास में ठप, IPFS आधारित: https://github.com/beardog108/seedbin

घोस्ट के सुझाव के अनुसार, मुझे पूरी तरह से विकेन्द्रीकृत (वितरित) Git होस्टिंग समाधान मिला और वे सहयोग में रुचि ले सकते हैं। मैं आज उनसे पूछ सकता हूं, अगर आप ठीक हैं: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

क्या इस पर कोई अपडेट है?
अतिरिक्त रखरखाव बाहरी सेवाओं को मेरे कार्यस्थल पर एक नो-गो बना देता है, लेकिन एक गीता कप सेवा हमारे लिए उपयोगी होगी।
यह फीचर मेरे लिए बहुत बड़ा प्लस होगा :)

मुझे लगता है कि यह गीता के रोडमैप में होना चाहिए।

हाँ, कृपया इसे जोड़ें!

इसे भी देखना पसंद करेंगे

हाँ, कृपया इसे जोड़ें!

इसे भी देखना पसंद करेंगे

कृपया, इश्यू-स्टार्टर टिप्पणी के लिए भावनाओं का उपयोग करें:

यह ईमेल के माध्यम से कई सब्सक्राइब किए गए लोगों को परेशान नहीं करेगा:

और इसकी अधिक कार्यक्षमता है:

मुझे सार के लिए सिप्स ((जीआई) चाय के संबंध में) नाम काफी पसंद है। :) कप भी अच्छा है, लेकिन मेरे लिए पूर्ण आकार के भंडारों को ध्यान में रखता है।

मेरे पास एक अधूरा पीआर नाम है यह कप

कॉमन यूनिक्स प्रिंटिंग सिस्टम? क्षमा करें: हंसना:

@ मिकेला हा! उस उपयोग के बारे में सोचा भी नहीं था।

@lunny मैं पीआर के माध्यम से देख रहा था कि क्या ऐसा कुछ है जिससे मैं मदद कर सकता हूं या बंद कर सकता हूं और मुझे पेस्टबिन, बिन, पेस्ट, कप, या कप से मेल खाने वाला कुछ भी नहीं मिला? अगर पहले से ही कुछ चल रहा है, तो इसे आगे बढ़ाने में मदद करने में मुझे खुशी होगी। या यहां तक ​​कि अगर वहाँ नहीं है, उस बात के लिए। बस प्रयास की नकल नहीं करना चाहता।

आर्क PKGBUILDs का उपयोग कर रहा है, Apple के pkgbuild के विपरीत।
कप के बजाय कप ठीक होना चाहिए। मुझे कोई संघर्ष नहीं दिख रहा है

कोई ख़बर?

नाम के लिए के रूप में

अगर हम चाहते हैं कि यह परिचित हो, तो यह gists होना चाहिए।

अगर हम चाहते हैं कि यह ब्रांड योग्य हो, तो sips मेरे लिए cups से अधिक मायने रखता है। हालाँकि, मैं इस तरह की एक सामान्य विशेषता की ब्रांडिंग के खिलाफ तर्क दूंगा।

Gitlab ब्रांडेड शब्दों का उपयोग करता है

गिटलैब के मामले में, उन्होंने "पुल अनुरोध" के बजाय "मर्ज अनुरोध" चुना, जो समझ में आता है कि यदि आप मूल जीथब बनाम "ऑटो-मर्ज" कार्यक्षमता पर "पुल अनुरोध" के ऐतिहासिक संदर्भ पर विचार करते हैं तो यह समझ में आता है कि यह बाद में विकसित हुआ।

हालांकि, मुझे आश्चर्य होगा अगर उन्होंने थोड़ा सा Google कीवर्ड प्लानर शोध नहीं किया और पता चला कि "मर्ज अनुरोध" शब्द का उपयोग करने से उन्हें किसी प्रकार का एसईओ लाभ मिला।

नया उपयोगकर्ता अनुभव

जैसा कि मैंने कहा, मैं व्यक्तिगत रूप से इसे एक ब्रांडेड नाम देने में बहुत अधिक मूल्य नहीं देखता।

एक नए उपयोगकर्ता के रूप में, यह उस तरह की चीज़ होगी जो मुझे अपनी आँखें घुमाती है और सोचती है:

हर किसी को एक ही चीज़ को अलग-अलग नामों से क्यों पुकारना पड़ता है, उह

अंतिम विचार

gist ट्रेडमार्क नहीं है, यह परिचित है, और यह समझ में आता है

यदि हम परिचित होने के लिए gist का उपयोग नहीं करते हैं, तो मेरा सुझाव है कि हम Google कीवर्ड प्लानर का उपयोग करके उद्देश्य पर एक नाम चुनें ताकि वे परिचित शब्द खोज सकें जिन्हें लोग "पेस्टबिन", "पोस्टबिन" पर पहुंचने पर ढूंढ रहे हैं। "जिस्ट", आदि।

मैं मर्ज अनुरोध से सहमत हूं, मेरे लिए बहुत अधिक समझ में आता है।

मुझे व्यक्तिगत रूप से अपने नाम का उपयोग करने का विचार पसंद है और मैं ईमानदारी से सोचता हूं, Google अनुक्रमणिका के लिए इसे दस्तावेज़ीकरण में बस इतना ही कहना पर्याप्त है:

"कप नोट्स को बचाने का एक समाधान है और यह जीथबगिस्ट और पेस्टबिन के समान है।"

ब्रांडिंग क्यों महत्वपूर्ण है

स्वयं के नाम समझ में आते हैं क्योंकि वे पहचान करने में मदद करते हैं - इसलिए हम सभी का एक ही नाम नहीं है।

कंपनियां अपनी आय का आधा हिस्सा ब्रांडिंग में निवेश करती हैं, पेप्सी का कहना है कि "हमें खुद के नाम की जरूरत नहीं है, बस इसे कोला कहें" बेतुका है।

इसके अलावा, आइए अद्वितीय विशेषताओं के बारे में बात करते हैं।

बस मेरे जीवन का अनुभव: जब आप गिटहब के बारे में बात कर रहे हैं, तो आपको पीआर (पुल अनुरोध) (या जनसंपर्क ?) का उपयोग करना चाहिए, जब आप गिटलैब के बारे में बात कर रहे हों - आपको एमआर (मर्ज अनुरोध) का उपयोग करना चाहिए। और अगर कोई GitLab से परिचित नहीं है, उदाहरण के लिए, यह इस तरह हो सकता है:

- कृपया, एमआर खोलें।
- श्री?
- हाँ, लाइक... GitHub में PR।

और कभी-कभी, खासकर यदि आप एक को दूसरे से ज्यादा पसंद करते हैं, तो आप एक गलती लिख सकते हैं जैसे:

— मैंने आपके GitHub प्रोजेक्ट के लिए MR खोला है।
- श्री?
- ओह, सॉरी, पीआर।

स्निपेट्स बनाम जिस्ट के बारे में भी ऐसा ही है।

आप गीता को अपनी इच्छानुसार बुला सकते हैं, लेकिन नए नामों से आप शब्दावली को फूला देंगे।

गिट्स क्यों नहीं? यह कहना आसान है, यह गीता को संदर्भित करता है, लेकिन अब जब मैं लिख रहा हूं.. अचानक... भगवान हो धिक्कार है.. मुझे गिटबिट्स बेहतर लगते हैं .. टिड्बिट्स की तरह थोड़ा।
हम्म .. अच्छा अगर ऐसा कोई प्लगइन आता है तो यह मीठा होगा! इसे जो कुछ भी कहा जाता है। वैसे गीता विकसित करने के लिए धन्यवाद। प्यारा सॉफ्टवेयर। मुझे एक फीचर भी चाहिए जब मैं अपने सर्वर/सर्वर कॉन्फिग फाइलों को सीधे गीता में संपादित कर सकूं। संस्करण इतिहास और सब कुछ के साथ।

व्यक्तिगत रूप से, मुझे परवाह नहीं है कि आप इसे क्या कहते हैं। मैं इसके बजाय पहले कार्यान्वयन पर ध्यान देना चाहूंगा।

आज मुझे एहसास हुआ कि एक स्क्रिप्ट को उन लिपियों के रेपो में नहीं होना चाहिए जिन्हें मैं साझा करने जा रहा था, लेकिन मैं उस स्क्रिप्ट को उसी तरह पुनः प्राप्त करना चाहता था जैसे मैं अन्य मशीनों से अन्य स्क्रिप्ट को पुनः प्राप्त करता हूं। संपूर्ण रेपो बनाना मूर्खतापूर्ण होगा।

इससे मुझे लगता है कि गोपनीय फाइलों को संग्रहीत करने, पुनर्प्राप्त करने और ट्रैक करने का एक अच्छा तरीका निजी सार है।

जब तक मैं यहां रहूंगा, मैं नामों पर विचार करूंगा। सच कहूं तो मुझे अब तक कोई पसंद नहीं है। मैं सुझाव देता हूं कि सेवा का नामकरण Gistea और एक स्निपेट एक पत्ता। जिस्टिया एक अद्वितीय कीवर्ड है, जबकि अभी भी गीता के सार के रूप में पहचाना जा सकता है, और पत्ते एक चतुर और आकर्षक सादृश्य हैं।

मुझे विशेष रूप से "कप" पसंद नहीं है। मुझे एक निश्चित मार्ज सिम्पसन दृश्य की याद दिलाता है। "कप ... क्या आप इसका जादू कर सकते हैं?"

मैं सुझाव देता हूं कि सेवा का नामकरण Gistea और एक स्निपेट एक पत्ता।

मुझे वह पसंद है: मासूम:

मुझे इस टिप्पणी में मॉकअप जैसा कुछ रखना अच्छा लगेगा। जब भी मैं कुछ नया सीख रहा होता हूं तो मुझे हमेशा लगता है कि मेरे पास अनौपचारिक जानकारी और नोट्स रखने के लिए अच्छी जगह नहीं है, खासकर उन चीजों के लिए जो किसी विशेष परियोजना में फिट नहीं होती हैं।

वास्तविक उपयोग के मामले के रूप में, मैं हाल ही में ड्रोन (सीआई) सीखने पर काम कर रहा हूं। चूंकि यह किसी भी परियोजना पर लागू होता है, मेरे लिए विचारों, उदाहरण, अनुस्मारक, युक्तियों आदि का दस्तावेजीकरण करने के लिए कहीं भी अच्छा नहीं है। एक व्याकुलता हो सकती है। मैं सिर्फ विकी का उपयोग करने के लिए एक परियोजना बना सकता था, लेकिन विकी को एक ऐसी संरचना की आवश्यकता होती है जो यादृच्छिक विचारों और विचारों का एक समूह एकत्र करने के लिए बहुत औपचारिक हो।

अभी मैं एक अलग प्रोजेक्ट पर बस गया हूं जहां मैं अनौपचारिक नोट्स के लिए इश्यू ट्रैकर का दुरुपयोग सिर्फ इसलिए करता हूं क्योंकि मैं उनमें लेबल जोड़ सकता हूं। सामान्य तौर पर मैं issue --> wiki --> formal docs का उपयोग करके प्रलेखन विकसित करने का प्रयास करता हूं, लेकिन यह लिनक्स सीएलआई युक्तियों आदि जैसी छोटी चीजों के लिए अच्छा काम नहीं करता है। लिंक की गई टिप्पणी में एक जैसा सेटअप जहां मैं चीजों को वर्गीकृत और टैग कर सकता था शानदार होगा। मैं इसे एक टन इस्तेमाल करूंगा।

https://github.com/fragmenta/fragmenta-cms
पोस्टग्रेस्क्ल गोलंग बिट्स हैं।
मोंगोडब गोलंग बिट्स माइस्क्ल, सिला/कैसंड्रा।
हालाँकि, कई पेस्टबिन सेवाएँ,
(कॉन्फ़िगरेशन फ़ाइल: जिस्ट, पास्टबिन.., वेटपेस्ट, आदि)

https://secrethub.io/ , एपीआई कुंजियों या रहस्यों को गिस्ट की तुलना में बक्से में वितरित करने के लिए थोड़ा बेहतर है।
Valt.io या इसी तरह की गुप्त वॉल्टिंग सेवाएं ....

My.dev.box , बनाम hacked.box.someplace.else
यूआईडी पासवर्ड, डीएनएस ओके...
अगर होम लोकेशन या होस्टिंग सर्वर में नहीं है
मारो .. अब यह।
सुरक्षा के लिए बक्सों बनाम सार का अनुमोदन कर सकते हैं।

आई टोटली वाना प्राइवेट जिस्ट माय एपी फ्लिपिंग की प्राइवेट...
एक टीम डेवलपर ब्लॉग पर कुछ गड़बड़ हो गई है, इसे दुर्घटना से ...

OSINT INTELLIGENCE, मेरी छिपी हुई सेवाओं का पर्दाफाश कर सकता है। यानी सार..

पायथन ओएसआईएनटी टूल्स, आपकी लाइसेंस प्लेट, आपका पता, सेलफोन, कैरियर इत्यादि।
गीथब/गिटलैब/आदि चाबियों के लिए एपीआई, एम्बेडेड पासवर्ड ....

इसलिए ब्लॉक स्ट्रिंग्स यानी पासवर्ड एपीआई कीज़ को फ़िल्टर करना
SANE भी साबित हो सकता है।

गो में लिखा एक विकल्प: https://dev.sigpipe.me/dashie/git.txt