:+1: 이 기능을 위해 이 기능의 이름을 컵 처럼 , , 로 지정하는 것이 좋습니다....

@laplix Common Unix Printing Service와 약간 혼동될 수 있습니다. 또한 +1도 합니다.

컵? 큐피? 아니면 단순히 Pastebin?

아니면 그냥 스 니펫, 멋진 이름이 아니라는 것을 압니다 ;)

나는 여전히(gogs 문제 참조) 이것이 외부 서비스여야 한다고 생각합니다. 그러나 우리는 그것을 Gitea에 주입 가능하게 만들 수 있습니다 🙂

옵션 기능:

) 댓글 섹션
) 개정(이력)
) Gist에서도 사용할 수 없는 구문 강조 표시
) 필터링 및 정렬

이 제안에 대한 많은 +1 및 별도로 생성된 많은 문제 보고서는 명확한 그림을 보여줍니다.

gogits/gogs#936

반면에 스니펫을 구현하는 것은 상당히 간단해야 합니다.

_snippets (또는 이와 유사한)라는 숨겨진 저장소를 유지하십시오. 각 스니펫은 폴더이고 폴더(또는 스니펫)에는 여러 파일이 포함될 수 있습니다. 완료 :)

@bkcsoft GitHub에서 각 스니펫은 Git 리포지토리(하지만 많은 파일을 포함할 수 있음)입니다. 하지만 우리는 다르게 만들 수 있습니다.

Gitea의 일부인지 아니면 별도의 프로젝트인지 모르겠습니다. Gitea에 있다면 코드를 재사용하는 것이 더 쉬울 것입니다.

어쨌든 많은 사람들(저 포함)이 Gists용 GitHub UI를 싫어한다는 사실을 명심해야 합니다. 우리가 더 잘할 수 있다고 생각합니다. 요점을 정리할 카테고리나 태그가 있어야 합니다. 기존 Gist를 쉽게 찾고 검색할 수 있어야 합니다.

하나 의 리포지토리에 모든 스니펫 포함:

장점:

• 편집기로 가져오기/동기화하기 쉽습니다.
• 구현하기 매우 쉽습니다.

단점:

• 스 니펫을 많이 사용하면 느려질 수 있습니다.
• 스 니펫을 완전히 제거하기가 어렵습니다 (기록 다시 작성, 좋지 않음)

Gist UI는 정말 짜증나... 개선해야 할 부분이 많고, 함께 해킹당한 느낌...

IMO 우리는 해당 리포지토리에 대한 스니펫과 관련된 모든 것을 포함해야 합니다(하나의 경우, 그렇지 않으면 하위 모듈 또는 그것들을 추적할 수 있는 모든 것...), 여기에는 카테고리(폴더 누구? :trollface:) 및 태그가 포함됩니다.

리포지토리에 파일로 저장하면 편집기에도 쉽게 동기화할 수 있으며 검색을 매우 간단하게 수행할 수 있습니다. 🙂

@andreynering 태그에 대해서도 생각했는데 좋은 생각입니다.
이 태그/카테고리를 왼쪽에 배치할 수 있습니다.
따라서 특정 pastebin을 쉽게 만들고 찾을 수 있습니다.

포크하고 조정할 수 있는 좋은 후보일 수 있습니다: https://github.com/defunkt/gist

또는 https://github.com/gmarik/Gistie

defunkt/gist 는 Gist와 대화하는 명령줄 도구이고 gmarik/Gistie 는 Ruby로 작성되었으며 둘 다 여기에서는 그다지 관련이 없습니다 🙂

순수한 golang 라이브러리가 선호됩니다.

@lunny @bkcsoft 제 경우에는 이 도구가 Gitea에서 도구를 사용하지 않고 Gitea에서 어떻게 작동하고 구현하는지 볼 수 있는 옵션으로 Gistie를 게시했습니다.

헤이스트 서버와 함께 사용할 수 있으므로 사람들이 공간에 대해 생각할 필요가 없습니다. 기본적으로 hastebin.com을 사용하고 자바스크립트를 사용하여 클라이언트에서 요청을 보내면 서버가 속도 제한을 받지 않습니다. 그러나 사용자가 자신의 가속 서버를 사용할 수도 있습니다. iframe을 사용하여 구현할 수 있습니다.

오늘 공유하고 싶은 멋진 도구를 찾았습니다: fssnip.net

원래 현상금에 추가되었습니다. 어쨌든, 나는 각 스니펫을 자체 리포지토리로 갖는 것이 히스토리 및 오프라인 수정이 진행되는 한 이를 수행하는 가장 좋은 방법이라고 생각합니다.

그런데 Bountysource 링크가 손상된 것 같습니다. 현재 총액은 다음과 같습니다.

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이 먼저 접근했습니다.

pastebin 서비스용 바이너리 파일? 좋은 생각이 아닙니다.

파일 확장자를 요구하지 마십시오. 그렇지 않으면 makefile을 공유할 수 없습니다.

@ptman @tboerger @techknowlogick이 내 의견을 업데이트했습니다.

일부 사람들은 시간 추적을 코어에 통합하는 방식을 좋아하지 않았기 때문에 giteas API와 긴밀하게 통합되고 저장소를 사용하여 페이스트를 저장하는 외부 서비스로 pastebins를 만드는 것은 어떻습니까?
Github pastebin조차도 일종의 외부 서비스라고 생각합니다 ...

@kolaente 기본값이 비활성화되어 있습니다. 하지만 외부 서비스로서 저장소, 이슈, 코멘트가 모두 준비되어 있기 때문에 내부보다 더 많은 작업이 필요합니다.

둘 다? 자체 솔루션과 함께 Github Gists?
그리고 내부 이름에 대한 Gitpin(s)?

소유자 편집: 작업을 위해 토론을 안전하게 유지하십시오...

+1

@lunny 이건 어때요. _snippets.git 저장소를 예약한 다음 외부 서비스에서 이를 스니펫에 사용하도록 하시겠습니까?

편집: 그렇게 하면 여전히 주석에 액세스할 수 있습니다(구현되고 병합되면 :trollface: ).

또는 .snippets.git .wiki.git ? 그리고 어떤 외부 서비스가 그렇게 하기에 적합합니까?

pastebin 서비스를 처리하는 외부 서비스가 있는 경우 이를 위해 저장소를 예약할 필요가 없다고 생각합니다.

그렇지 않고, 우리가 gitea에서 pastebin 서비스를 구현한다면 나는 예약된 리포지토리의 아이디어를 좋아할 것입니다. 페이스트는 일반적으로 그다지 많지 않기 때문에 매번 리포지토리를 만들 필요가 없다고 생각합니다. 일부 페이스트를 생성할 때 시간이 지나면 너무 많은 리포지토리가 생성됩니다.

단일 저장소를 사용할 수 있고 각 붙여넣기에 대해 새 분기를 사용할 수 있다고 생각합니다.

붙여 넣기 당 저장소가 없어야 할 이유가 있습니까? GitHub의 Gists에 대한 가장 멋진 점 중 하나는 실제로 복제하고 커밋할 수 있는 전체 저장소라는 것입니다.

나도 그렇게 본다 54

+1

가능하면 사용자 지정 pastebin 서비스로 연결되는 버튼을 간단히 만들 수 있습니까?

이것은 우리에게 몇 가지 이점을 제공합니다: 매우 빠른 개발 및 사용자 정의.
솔직히:
이 문제를 작성한 이후 선호하는 언어가 변경되었으며 pastebin 서비스는 도구 설명과 라이브러리도 지원합니다.

Gitea 구현은 나중에 여전히 가능하며 이것은 추가 노력이 전혀 필요하지 않습니다.

나는 외부 pastebin 서비스에 찬성하지 않습니다. 우리 회사에서 Gitea를 사용하는 이유는 보안 및 내부 액세스를 위해 내부 네트워크 안에 있기 때문입니다. 우리는 외부 서비스를 사용할 수 없습니다. 그렇지 않으면 github 또는 bitbucket을 사용할 것입니다. gitea에서 구현하려는 방법을 결정하고 쓰레기 대안으로 산만하지 않도록 노력해야 합니다.

어쨌든 마스터 버전에서는 사용자 정의 템플릿의 외부 링크에 사용자 정의 탭을 추가할 수 있습니다

"외부"는 반드시 "다른 사람에 의해 실행됨"을 의미하지 않습니다.
모듈화에는 장점도 있습니다...

@ShalokShalom 나는 링크가 가능한 첫 번째 단계가 될 것이라는 데 동의합니다. 어쩌면 누군가를 짜증나게 하여 더 나은 것을 만들기 위한 것일 수도 있습니다.

@strk는 확실하지만 모듈화만 원하고 통합은 필요하지 않은 경우 문제 추적 기능이 있는 이유는 무엇입니까? 릴리스? gitosis가 제공하는 것 이외의 모든 것

@lafriks 정말? 어떻게?

@ptman 글쎄, 다른 페이지와 자체 솔루션에 대한 링크를 모두 통합하려면 IS 모듈식입니까?

@lukewatts @strk 에 대한 아이디어가 괜찮습니까?

@ShalokShalom 통합 솔루션을 사용할 수 있게 되면 링크가 사라질 것으로 예상합니다.

일반 작업에 대한 링크는 어쨌든 도움이 됩니다. 프로젝트 페이지 등에 링크할 수 있습니다.

그리고 내부 솔루션에는 나에게 중요한 기능이 부족할 것입니다.

구문 강조 표시는 매우 초기 상태입니다.

Tooltips 에 대한 것보다 어떻습니까?

@ShalokShalom 예, https://docs.gitea.io/en-us/customizing-gitea/ "링크 및 탭 추가" 섹션 참조(#3308에 추가됨)

감사합니다 ^_^

@ShalokShalom 외부 서비스에 대한 링크가 긴 손가락에 최종 솔루션을 넣을 핑계가되지 않는 한 사용자 정의 링크가 좋을 것 같습니다..
바둑을 알면 그냥 욕하기보다 도와줄 텐데. 저는 합리적인 시간에 완성된 훌륭한 솔루션에 더 가까이 다가갈 수 있는 모든 것에 찬성합니다.

직접 호스팅하는 한 내부 서비스에도 연결할 수 있습니까?

나를 위해 GitHub 요지와 같은 것은 할 수 있지만 몇 가지 개선 사항을 다음과 같이 만들 수 있다면
태그/카테고리
또는 분명히 플러스가 될 미디엄/블로그 스타일 형식

복잡하지 않고 gitea에 통합하는 것이 giteas 철학에 가장 적합하다고 생각합니다.

손쉬운 자체 호스팅 Git 서비스입니다.

BitTorrent, IPFS 또는 privEOS를 사용하여 탈중앙화할 기회에 주목. 나는 데이터로 소유하는 것을 좋아하지만 이를 위해 더 연합된 것이 있으면 보기에 좋은 스파이크가 될 것입니다.

따라서 이 요청은 이제 2년이 넘었습니다. 이에 대해 어떤 진전이 있었는지 궁금합니다.

아무도 이 작업을 하지 않습니다.

이제 oauth 지원이 있으므로 외부 항목을 빌드할 수 있습니다.

예, @ShalokShalom 의 이미지가 아름답다고 생각합니다 https://github.com/go-gitea/gitea/issues/693#issuecomment -274277781

@lunny 플라 럼입니다.

삭제된 사용자 의 아이디어가 마음에 듭니다.
러니가 제안한 것처럼 컵에도 이름을 붙였습니다. ^^

그래서 분배된 컵. :하트: - :하트:
컵 몇 개를 나누고 다과회를 합시다. :디

그 목적을 위해 일부 라이브러리(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 컵 서비스를 사용할 수 있습니다.
이 기능은 저에게 큰 장점이 될 것입니다 :)

나는 이것이 Gitea의 로드맵에 있어야 한다고 생각합니다.

예, 이것을 추가하십시오!

이것도 보고싶다

예, 이것을 추가하십시오!

이것도 보고싶다

이슈 스타터 코멘트에 감정을 사용하십시오:

이메일을 통해 구독한 많은 사람들을 방해하지 않습니다.

더 많은 기능이 있습니다.

나는 요점에 대해 Sips((gi)Tea와 관련하여)라는 이름을 아주 좋아합니다. :) 컵도 좋지만 전체 크기의 저장소가 생각납니다.

미완성된 PR 이름이 있습니다.

일반적인 유닉스 인쇄 시스템? 죄송합니다:웃음:

@미카엘라 하! 그 용도는 생각도 못했네요.

@lunny PR을 살펴보고 도움을 줄 수 있는 항목이 있는지 확인했는데 pastebin, bin, paste, cup 또는 컵과 일치하는 항목이 없었습니까? 이미 진행 중인 일이 있다면 기꺼이 도와드리겠습니다. 또는 없는 경우에도 마찬가지입니다. 노력을 반복하고 싶지 않을 뿐입니다.

Arch는 Apple의 pkgbuild와 달리 PKGBUILD를 사용하고 있습니다.
CUPS 대신 컵이 좋습니다. 나는 투쟁을 보지 않는다

소식이 있나요?

이름에 관해서

친숙하게 하려면 gists 이어야 합니다.

브랜드화할 수 있게 하려면 cups sips 가 더 합리적입니다. 그러나 나는 그러한 일반적인 기능을 브랜딩하는 것에 대해 반대합니다.

Gitlab은 브랜드 용어를 사용합니다.

Gitlab의 경우 "pull request" 대신 "merge request"를 선택했는데, 이는 "Pull Request"가 원래 Github에 있었던 것과 "자동 병합" 기능이 있었던 역사적 맥락을 고려하면 의미가 있습니다. 나중에 로 발전했습니다.

그러나 그들이 약간의 Google Keyword Planner 연구도 하지 않고 "Merge Request"라는 용어를 사용하는 것이 SEO 이점을 제공한다는 사실을 발견했다면 놀랐을 것입니다.

새로운 사용자 경험

내가 말했듯이, 나는 개인적으로 브랜드 이름을 부여하는 데 많은 가치가 있다고 보지 않습니다.

새로운 사용자로서, 그것은 내가 눈을 감고 생각하게 만드는 종류의 것입니다.

왜 같은 걸 다른 이름으로 불러야 하는지 uh

마지막 생각들

gist 는 상표가 아니며 친숙하며 의미가 있습니다.

친숙하기 위해 gist 를 사용하지 않는 경우 Google 키워드 플래너를 사용하여 사람들이 "pastebin", "postbin", "요점" 등

나는 병합 요청에 동의하고 나에게 훨씬 더 의미가 있습니다.

저는 개인적으로 자신의 이름을 사용하는 아이디어를 좋아하며 솔직히 생각합니다. Google 색인의 경우 문서에서 다음과 같이 간단히 표현하는 것으로 충분합니다.

"컵은 메모를 저장하는 솔루션이며 GithubGist 및 Pastebin이 제공하는 것과 유사합니다."

브랜딩이 중요한 이유

자신의 이름은 식별에 도움이 되기 때문에 의미가 있습니다. 그래서 우리 모두는 같은 이름을 가지고 있지 않습니다.

회사는 수입의 절반 정도를 브랜딩에 투자합니다. Pepsi는 "우리는 자신의 이름이 필요 없고 그냥 콜라라고 부르기만 하면 됩니다"라고 말하는 것은 터무니없는 말입니다.

또한 고유한 기능에 대해 이야기해 보겠습니다.

제 인생 경험입니다. GitHub에 대해 이야기할 때는 PR(Pull Requests)(또는 Public Relations ?)을 사용해야 하고 GitLab에 대해 이야기할 때는 MR(Merge Requests)을 사용해야 합니다. 예를 들어 누군가 GitLab에 익숙하지 않은 경우 다음과 같을 수 있습니다.

— MR을 열어주세요.
- 씨?
— 예, 예를 들면... GitHub의 PR입니다.

그리고 때때로, 특히 다른 것보다 더 마음에 들면 다음과 같은 실수를 쓸 수 있습니다.

— GitHub 프로젝트용 MR을 열었습니다.
- 씨?
— 아, 죄송합니다, 홍보님.

스니펫 대 요지에 대해서도 동일합니다.

원하는 대로 Gitea를 호출할 수 있지만 새 이름을 사용하면 용어가 부풀려집니다.

왜 안되지? gitea 라고 하기엔 쉽지만 지금 쓰다보니.. 갑자기... God be Damned.. 난 gitbits가 더 좋아.. 약간 tidbits 같은..
흠 .. 그런 플러그인이 있으면 달콤 할 것입니다! 그것이 무엇이든간에. 그나저나 gitea를 개발해주셔서 감사합니다. 사랑스러운 소프트웨어. 또한 Gitea에서 직접 서버/서버 구성 파일을 편집할 수 있는 기능을 원합니다. 버전 기록 및 모든 것.

개인적으로 나는 당신이 그것을 뭐라고 부르든 상관하지 않습니다. 우선 구현에 중점을 두는 것이 좋습니다.

오늘 저는 공유할 스크립트 저장소에 단일 스크립트가 없어야 한다는 것을 깨달았지만 다른 컴퓨터에서 다른 스크립트를 검색하는 것과 같은 방식으로 해당 스크립트를 검색하고 싶었습니다. 전체 repo를 만드는 것은 어리석은 일입니다.

그것은 사적인 요지가 비밀 파일을 저장, 검색 및 추적하는 좋은 방법이라고 생각하게 합니다.

내가 여기 있는 동안 이름을 부르겠습니다. 솔직히 지금까지는 마음에 들지 않습니다. 서비스 Gistea와 스니펫의 이름을 Leaf로 지정하는 것이 좋습니다. Gistea는 여전히 Gitea의 요지로 인식되는 독특한 키워드이며 잎은 영리하고 매력적인 비유입니다.

나는 특히 "컵"을 좋아하지 않습니다. 마지 심슨의 어떤 장면이 생각납니다. "컵... 철자 좀 써줄 수 있어?"

서비스 Gistea와 스니펫의 이름을 Leaf로 지정하는 것이 좋습니다.

나는 그것을 좋아한다 :innocent:

나는 이 의견 에 모형과 같은 것을 갖고 싶습니다. 새로운 것을 배울 때마다 특히 특정 프로젝트에 맞지 않는 경우 비공식적인 정보와 메모를 남길 수 있는 좋은 장소가 없다고 항상 느낍니다.

실제 사용 사례로 최근에 Drone(CI)을 배우는 작업을 하고 있습니다. 그것은 모든 프로젝트에 적용되기 때문에 아이디어, 예, 알림, 팁 등을 문서화하기에 좋은 곳은 없습니다. 나는 내 자신의 지침에 대한 문서 사이트를 시작할 만큼 충분히 알지 못합니다. 방해가 될 수 있습니다. Wiki를 사용하여 프로젝트를 만들 수도 있지만 Wiki는 임의의 생각과 아이디어를 모으기에는 너무 형식적인 구조가 필요합니다.

지금은 레이블을 추가할 수 있다는 이유만으로 비공식 메모에 문제 추적기를 오용하는 별도의 프로젝트에 정착했습니다. 일반적으로 나는 issue --> wiki --> formal docs 를 사용하여 문서를 발전시키려고 하지만 Linux CLI 팁 등과 같은 작은 일에는 잘 작동하지 않습니다. 내가 분류하고 태그를 지정할 수 있는 링크된 주석의 설정과 같은 설정 환상적일 것입니다. 나는 그것을 톤으로 사용할 것입니다.

https://github.com/fragmenta/fragmenta-cms
postgresql golang 비트가 있습니다.
Mongodb golang은 mysql, sylla/Cassandra를 비트합니다.
그러나 thiers, 수많은 pastebin 서비스,
( 구성 파일: gist, pastbin.. , wetpaste 등 )

https://secrethub.io/ , API 키 또는 비밀이 요점보다 상자에 배포되는 것이 조금 더 좋습니다.
Valt.io 또는 이와 유사한 비밀 금고 서비스....

My.dev.box 대 hacked.box.someplace.else
UID 암호, DNS 확인 ...
집 위치 또는 호스팅 서버가 아닌 경우
죽여.. 지금.
보안을 위해 상자와 요지를 증명할 수 있습니다.

나는 내 API가 비공개 키를 뒤집는 요점을 완전히 원합니다 ...
팀 개발자가 우연히 블로그에 글을 남겼습니다...

OSINT INTELLIGENCE는 숨겨진 서비스를 공개할 수 있습니다. 즉 요지..

Python OSINT 도구, 번호판, 주소, 휴대폰, 이동통신사 등
키 API용 Github/gitlab/etc , 포함된 비밀번호....

따라서 블록 문자열, 즉 암호 API 키 필터링
SANE을 증명할 수도 있습니다.

go로 작성된 대안: https://dev.sigpipe.me/dashie/git.txt