• 1

이것이 어떤 식으로든 확장으로 노출된다면 멋질 것입니다. 어떤 경우에는 나무가 색에 약간 오염되어 크리스마스 트리처럼 보일 수 있다는 것이 걱정됩니다. 또는 그렇지 않은 경우 최소한 켜고 끌 수 있는 옵션이 있습니다.

그래, 난 동의. 이것을 확장 API에 노출시키기 위해 별도의 문제를 만들었습니다(#1394 참조).

+1

그것도 좋아할 것입니다. Git 탭은 매우 편리하지만 이것은 또 다른 목적을 위한 것입니다. Atom과 같은 색상을 사용하면 변경 사항과 위치를 한 눈에 볼 수 있어 매우 무료입니다(색상이 최상위 디렉토리까지 자동으로 전파됨). 아마 Atom에서 가장 그리운 기능일 것입니다.

일반적으로 커밋되지 않은 수정된 파일이 10~100개가 없으므로 크리스마스 트리처럼 보이지 않을 것입니다. :)

그래서 이에 대한 PR이 종료된 것 같습니다. @bpasero @joaomoreno - 이 작업의 상태에 대한 업데이트가 있습니까?

https://github.com/Microsoft/vscode/pull/8462를 확인

업데이트가 없습니다...

이 문제에 관심을 가져주셔서 감사합니다! 현재 백로그에 할당되어 있습니다. 매달 우리는 백로그에서 항목을 선택하여 현재 반복을 계획합니다. 자세한 내용은 https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning 을 참조

우리는 소규모 개발자 팀이기 때문에 하나의 이정표에 대해 작업할 수 있는 기능 요청과 문제가 너무 많습니다. 그럼에도 불구하고 우리는 항상 풀 리퀘스트를 환영하며 그들이 우리의 품질 기준을 충족한다면 기꺼이 수락합니다.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 쓰지 마세요. 문제의 모든 사람에게 이메일을 보냅니다. 첫 댓글에 이모티콘 반응을 사용하세요.

+1

안녕하세요, 이 기능 요청에 대한 소식이 있습니까? 오늘 vscode를 사용하기 시작했고 이미 사랑하고 있지만 변경 사항을 나타내는 색상이 정말 그리워요
당신의 일을 축하합니다

+1

이것을 구현하는 동안 206을 고려하십시오.

도움이 되도록 몇 가지 스크린샷을 추가합니다.

원자 기본값:

VSCode 기본값:

+1

+1

이것은 매우 유용할 것입니다.

파일 및 아이콘이 파일 트리에 나열되는 방식을 수정할 수 있는 기능이 이미 있습니다.
이 확장 기능은
https://github.com/robertohuertasm/vscode-icons.

그러나 파일 이름은 색칠하지 않습니다.

+1

+1

어떤 변화가 있습니까? 이 기능은 내가 Atom에서 움직이지 못하게 합니다. :(

VSC에서 성능이 훨씬 좋아지기 때문에 Atom에서 멀리 옮겼습니다. 그러나 이것은 내가 VSC에서 그리워하는 고급 기능입니다.

+1

확장 기능 대신 내장 설정(예: git.colorExplorer )으로 이것을 갖는 것이 좋을 것 같습니다.

@arkon 그러한 확장이 있습니까? 나는 아무것도 찾을 수 없습니다.

파일 탐색기에는 파일을 수정하는 API가 없을 가능성이 큽니다.
git 변경합니다. 확장 프로그램은 나에게 적합합니다.

2017년 2월 3일 금요일 07:52 Rahul [email protected]에서 다음과 같이 썼습니다.

@arkon https://github.com/arkon 그러한 확장이 있습니까? 나는 할 수 없었다
아무거나 찾으십시오.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@rahulnever2far 아니요, 이전에 확장 API로 노출될 수 있다고 제안했기 때문에 제안일 뿐입니다(이것도 괜찮습니다).

최근에 VSCode로 이동하기로 결정했는데 이 기능이 정말 그립습니다.

추가하십시오. Atom에서 점프하려고 할 때 생산성에 마찰을 추가합니다.

@KozhokarAlex @bhudgens 및 기타: 이 기능을 요청하는 개발자를 표시하려면 첫 번째 게시물에서 엄지손가락 아이콘을 클릭하세요. 가장 인기 있는 기능 요청을 결정 하기 위해

이러한 종류의 문제 정렬에서 알 수 있듯이 이 문제는 현재 세 번째로 많이 요청되는 기능입니다.

좋아요. 최근에 Atom에서 왔습니다. 곧 VSCode에서 볼 수 있기를 바랍니다!

아 감사합니다 @joaomoreno!

FileExplorer뿐만 아니라 QuickOpen에도 동일한 색상/QIT 상태를 추가하십시오.
이렇게 하면 이미 변경된 파일을 기반으로 파일을 여는 것을 시각적으로 필터링할 수 있습니다.

이게 무슨 일이야? 유지 관리자가 @joaomoreno PR을 병합하지 않는 이유는 무엇입니까? 지금 사용할 수 있는 플러그인이 있습니까? 이것은 단지 어리석은 계획입니다

@SOSANA PR이 무슨 말인지 잘 모르겠는데 어떤 PR을 말씀하시는 건가요?

2824가 이 문제를 해결하기 위해 문을 열었으니 조금만 더 참으세요.

@SOSANA 홍보가 아니라 문제입니다 🤣

+1 이 기능은 생산성에 놀랍습니다.

+1

@ publiclass1 @ hevans90, (+1 주석으로 다른 모든 사람들 삽입) ...,이 기능을 원하는 얼마나 대해 게시하지 의견을주십시오. 이것이 GitHub가 이모티콘 반응을 추가한 이유입니다. 그냥 원래 댓글에 엄지손가락을 치켜세우세요. 그렇게 하면 이메일 알림을 원래 의도했던 대로 다시 사용할 수 있습니다(이 문제의 진행 상황에 대해 계속 업데이트하고 전 세계의 누구도 이를 원하지 않음). 스팸메일을 보내주신 모든 분들께도 죄송합니다. 더 많은 사람들이 +1 문제를 중지하는 방법을 배우기를 진심으로 바랍니다.

+1

나는 PhpStorm을 사용하지만 모든 것에 VS Code를 사용하고 싶습니다. 현재 가능한 한 많은 VS Code 창을 사용하고 있습니다. 내가 / 선호하는 PhpStorm 색상을 알고 당신은 기쁘게 결국 옵션으로이 착색 시스템을 가지고 있습니다. 참고로:

검은색 - 최신 - 파일이 변경되지 않았습니다.
회색 - 삭제됨 - 파일이 저장소에서 삭제되도록 예약되었습니다.
파란색 - 수정됨 - 마지막 동기화 이후 파일이 변경되었습니다.
녹색 - 추가됨 - 파일이 리포지토리에 추가되도록 예약되었습니다.
갈색 - 알 수 없음 - 파일이 로컬에 있지만 저장소에 없고 추가할 예정이 없습니다.

등을 통해 https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . 당신은 록, 감사합니다.

그리고

• 충돌로 병합된 파일은 빨간색으로 표시되고,

갈등을 다른 사람들과 구별하는 것은 매우 편리합니다.

+1 Git <> Explorer 보기 사이를 앞뒤로 토글해야 하는 것은 매우 비생산적입니다.

이상적으로는 Open 파일이 있는 맨 위에 변경 집합을 그룹으로 볼 수 있을 뿐만 아니라 색상으로 시각화된 중첩된 변경 트리(위의 @abdonrd 로 표시됨)도

얘들아, 그냥 +1로 그만해.

첫글에 엄지척 부탁드립니다.

플러그인이 개별 파일과 폴더의 색상을 지정할 수 있도록 하는 일반 API를 만드는 흥미로운 사용 사례와 인수가 있습니다.

Trello 에이징 파워업과 유사한 파일/폴더 에이징 - 오랫동안 손대지 않은 파일 및 폴더(git history로 판단)를 페이드 아웃하여 '작업 세트'가 더 뚜렷하고 더 쉽게 찾을 수 있습니다.

이유: 작업의 90% 이상을 다시 다루지 않을 작은 프로젝트(분석 보고서를 위한 스크립트를 많이 생각해 보세요)가 있는 큰 저장소가 있습니다. repo를 가리키는 링크).

트리 항목을 색칠하기 위한 API 끝점이 있다면 git 로그를 읽고 몇 가지 규칙에 따라 각 파일/폴더를 색칠하는 플러그인을 작성할 수 있습니다.

그렇다면 이에 대한 확장을 생성할 수 있는 API가 아직 있습니까? 아니면 통합 기능으로 구현될 예정입니까?

이에 대한 업데이트가 있습니까?

+1

+1

+1

저희 메일 받은 편지함에서 +1 및 스팸을 중지해 주시겠습니까 ???

전혀 목적이 없습니다.

스팸 없음 xD에 +1

protip: 본문이 같음/일치/lolwuts "+1"인 github에서 메시지를 필터링합니다.

당신은 이 사람들을 막을 수 없습니다.

@jmbelloteau 는 @fredrikaverpil 이 주석의 앞부분에서 말했듯이 VSCode 문제는 원래 주석에 대한 엄지손가락 수에 따라 정렬됩니다. 따라서 첫 번째 댓글에 대한 반응을 추가하는 대신 "+1"을 추가하는 것은 실제로 스팸입니다. 피드백을 제공하는 올바른 방법이 아니며 모든 사람에게 쓸모없는 이메일만 보내기 때문입니다. 그리고 반응을 추가하는 것과 달리 고려조차 하지 않습니다.

+1

웹스톰에서도 너무 익숙해요 :D. 그러나 내가 볼 수 있듯이 이것은 아마도 나중에 더 빨리 개발될 것입니다. 다음은 영감을 얻기 위한 Webstorm의 스크린샷입니다(@abdonrd 다음):

아, 추적되지 않은 파일도 빨간색으로 표시됩니다!

+1

오늘 처음으로 VS 코드를 시도했고(Atom에서 제공) 내가 검색한 첫 번째 확장 중 하나는 탐색기 보기에서 강조 표시된 "git status"였습니다. "소스 제어" 탭 자체는 매우 훌륭하지만 폴더/파일을 강조 표시하면 항상 디렉터리 트리를 확장된 상태로 두지 않고도 작업 중인 구성 요소로 빠르게 이동할 수 있습니다. 더 깊이 중첩된 구조를 가짐).

이상적으로는 색상을 개별적으로 수정할 수 있다면 좋을 것입니다.

{
    git.newFileColor: 'green',
    git.changedFileColor: 'yellow',
    git.untrackedFileColor: 'blue',
    git.ignoredFileColor: 'gray,
    git.mergeConflictFileColor: 'red'
}

+1

물 마시라고 알려주는 좋은 앱을 한참 찾았습니다.
그러다가 내가 이 스레드에 가입했다는 것을 깨달았습니다.
계속해서 +1하는 녀석들, 그들은 더 이상 쓸모가 없습니다 🚰

@mmazzarolo
물 마시기 알림이 필요한 이유는 무엇입니까? 목이 마를 때 마시는 것으로 충분하지 않습니까?

어쨌든 +1-ing은 멈춰주세요. 나는 개발자들이 이미 이것을 알고 있고 그들이 오는 대로 업데이트를 게시할 것이라고 확신합니다.

@pohmelie 유효한 대안입니다, 감사합니다!

+1

wtf가 이 +1명에게 잘못되었나요?

좋은 생각입니다, @davidhu2000! git.ignoredFileColor: '#333333' 와 같은 16진수 색상도 지원하는 것이 좋습니다.

JetBrains가 사용하는 유형 및 색상 목록은 https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html입니다 (색상 이름을 검사하여 16진수를 얻을 수 있음).

+1 이 기능이 얼마나 필요한지에 대한 인식 제고

내가 VS 코드를 사용하지 않는 유일한 이유. 너무 나쁘다 :(

누구든지 코드베이스에서 이것을 구현하기 시작할 위치를 알고 있습니까? 나는 그것을 찔러보고 싶다.

@admosity 누군가가 작년에 이미 pull 요청을 제출했지만 거부되었습니다: https://github.com/Microsoft/vscode/pull/8462 .

2824는 위에서 어딘가에 차단기로 언급되었으며 얼마 전에 병합되었습니다. VS-Team이 원하는 방식으로 구현되었는지 확인하기 위해 변경 사항을 살펴보겠습니다.

@AndreasGassmann 굉장합니다! 살펴보겠습니다.

마지막 핵심 기능으로 vs 코드로 전환할 수 없습니다.

이 기능이 통합되면 vscode로 변경하겠습니다.

진행 상황이 언제 완료되는지 알고 싶기 때문에 이 문제를 구독했습니다.
이 기능이 얼마나 필요한지 모두가 알고 있으며 현재 두 번째로 많이 찬성된 문제 입니다. :).

이 기능을 정말로 원한다면 첫 번째 댓글에 찬성표를 던지고 반복되는 댓글을 추가하지 마십시오 .

이 기능이 VS Code로 전환하는 데 필요하다고 생각하는 사람들을 위해. Atom에서 전환할 때 놓친 첫 번째 기능이라고 말할 수 있지만 IMO는 이 멋진 IDE에 지불하기에는 작은 가격입니다.
게다가 지난 주에 Atom에서 작업을 해야 했고 VS Code의 git 보기가 정말 그리웠습니다.

@waderyan 이것은 원자에서 이동하는 거래

예, 부탁합니다!

+1

+1

+1

workbench.main.js 를 수정하고 git status 출력을 기반으로 CSS를 삽입하여 이 기능을 구현하는 매우 추악한 해킹을 만들었습니다. VS Code 내부 파일을 파헤치고 VS Code가 5초마다 git status 실행하도록 하는 데 신경 쓰지 않는다면 살펴보세요.

https://github.com/karabaja4/vscode-explorer-git-status

업데이트 28.6.2017: 프로젝트를 다시 열 때 플러그인이 로드되지 않는 버그가 수정되었습니다.
2017년 30월 6일 업데이트: 수정된 파일의 상위 디렉토리 강조 표시가 추가되었습니다(Atom처럼).
업데이트 1.7.2017: 이제 파일 일치가 전체 파일 또는 디렉터리 경로를 사용하여 수행됩니다. 이 변경 전에 디렉토리가 변경된 다른 디렉토리와 이름이 같은 경우 강조 표시되었습니다.

안녕하십니까,
이 기능이 구현되었는지 여부를 아직 알 수 없습니까?
설정이나 확장을 찾지 못했는데 거의 2년 전에 오픈해서 헷갈리네요..

@sanjibukai 이 문제는 아직 열려 있으므로 아직 구현되지 않았습니다. 위의 댓글에서 @karabaja4가 만든 해킹을 사용할 수 있습니다.

저는 여기 새롭지만 이 명백한 기능을 추가하는 데 거의 2년이 필요합니까?
나는 놀랍게도 최근까지 vscode에 대해 들어본 적이 없지만, 그것에 대해 들었을 때 옹호된 주요 기능은 정확히 어떻게 vscode가 git을 잘 통합하는지입니다. 그리고 실제로 좋습니다.
이 기능이 아직 부족한게 아쉽네요..
그래도 vscode팀 힘내세요👍

이 기능이 없으면 집중할 수 없습니다. 내가 편집한 파일을 기억해야 할 때마다.

+1

@karabaja4 해킹으로 PR을 하고 제대로 구현하는 방법에 대한 피드백을 받아보는 건 어떨까요?

@saada 그 코드 중 하나라도 VS Code에 통합될 수 있다고 생각하면 그렇게 할 것입니다. 백그라운드 git status 프로세스를 실행하는 것은 이 기능을 구현하는 올바른 방법이 아닙니다. 이를 구현하는 모든 적절한 코드는 처음부터 작성하고 VS Code 소스 프레임워크 내에서 올바르게 구현해야 합니다. 그것은 많은 작업이며 불행히도 현재 시간이 충분하지 않습니다. 죄송합니다 :(

그들이 언급한 지표가 답글이 아니라 원래 게시물이 받은 +1의 숫자라고 이미 말했을 때 쌓이는 것은 도움이 되지 않을 것입니다. 또한 이것이 개발자를 위한 도구라는 점을 고려하면 여기에서 진행 중인 오픈 소스 프로세스를 이해하지 못하고 얼마나 많은 권한이 있는지에 대해 약간 놀랐습니다. 기능 요청은 공개 문제로 여기에 있습니다. 게시물에서 +1하고 직접 수행(아마도 유지보수자와 협력하여 헛되지 않은지 확인)하고 병합을 요청하거나 그대로 두십시오. 중요한 기능이라면 Atom을 사용하십시오. 이 글을 쓰는 현재 4000개가 넘는 미해결 문제가 있습니다. 인내심을 발휘해야 합니다.

(또는 그동안 @karabaja4 hack을 사용하세요. 작업해주셔서 감사합니다!)

+1
devchat 에 대한 이야기를 듣고 더 많은 의견이 있는 문제가 더 많은 관심을 받을 수 있기 때문에 이것을 하는 것입니다.

@karabaja4 훌륭한 작품입니다. 또 다른 접근 방식: 초기화 시 git status 를 실행한 다음 onFileSave 이벤트가 발생할 때마다 업데이트하는 것은 어떻습니까? 이게 더 효율적이지 않을까요?

git 상태를 새로 고치는 방법을 구성할 수 있습니다.

+1 추가하면 매우 유용할 것입니다.

@Kaijun 어떻게 구현해야 할지 모르겠습니다. onFileSave 이벤트의 출처는 어디인가요?

문서 저장 시 코드에서 가져온 경우(첨부 방법을 알고 있다고 가정) 코드 외부에서 수정된 파일은 무시되고 파일 이동 및 복사와 같은 변경 사항도 무시됩니다.

솔루션 트리에 구현된 폴더 감시 논리에서 가져온 경우 전체 트리에 대해 재귀적으로 수행해야 합니다. 성능면에서 가치가 있는지 확실하지 않습니다.

@karabaja4 코드가 외부 변경 사항도 감지한다고 생각합니다. 따라서 동일한 간격의 여러 파일 변경이 너무 많은 자식 상태 검사를 트리거하지 않도록 디바운스 시스템을 사용하여 이러한 "이벤트"에 연결합니다. 이것은 작동할 수 있습니다!. 아마도 fs 조각에 익숙한 사람이 끼어들 수 있습니까?

이것은 정말로 백로그에 있어서는 안됩니다. 이 겉보기에 작은 기능을 추가하는 것은 매우 실질적인 가치가 있습니다. 개발자의 행복은 계속됩니다. 이 문제를 보고 실망하면 수천 개의 +1이 있으며 2015년부터 무시되었습니다.

@kamok 맞아요 ! Atom은 느리지만 다른 옵션이 있습니다... WebStorm으로 돌아갔습니다. WebStorm은 Git과 통합하고 vscode에 확장 프로그램을 설치해야 하는 다른 기능과 통합하는 방식에서 무패입니다. 그리고 여전히 너무 빠릅니다. 속도 면에서 IDE라기보다는 가벼운 편집기처럼 보입니다. 이 기능만으로는(파일 탐색기의 Git 상태) 여전히 vscode 사용자를 유지하기에 충분하지 않습니다. 이것은 양동이에 한 방울일 것입니다. WebStorm에서 내가 가장 그리워하는 기능입니다.
저는 vscode 팀이 JetBrains의 직원들이 어떻게 하고 있는지 살펴볼 것을 제안합니다.
죄송합니다. 하지만 시도했습니다... 저는 몇 달 동안 vscode와 씨름하고 업데이트 후 업데이트를 기다렸지만 계속해서 계속해서 vscode를 닫고 WebStorm에서 프로젝트를 다시 여는 자신을 발견했습니다. 탐색기의 Git 상태 트리, 숨김, 로컬 변경 사항에 대한 폴더/트리 보기, 분기 비교, 마우스 오른쪽 버튼 클릭 > 클립보드와 비교... 그리고 이것들은 내 머리 꼭대기에 있습니다. Vscode Git 통합은 개발자를 정말로 돕고 싶다면 아직 갈 길이 멉니다.

_FastHub를 사용하여 Samsung SM-G950F에서 전송 _

@MrCroft 팀의 작업 방법론에 대해 우려하는 경우 팀에 직접 연락하는 것이 좋습니다. 그렇지 않으면 엄지손가락으로 문제를 +1하고 너무

@cucumbur 이미 했습니다(vscode에서 전환). 나는 vscode가 어떤 느낌인지 정말 좋아했기 때문에 내 슬픔을 말하는 것입니다. 나는 그것을 계속 사용할 수 있도록 좋은 Git 통합이 있었으면 좋았을 것입니다. 많은 사람들이 같은 느낌을 받을 것이라고 확신합니다.
계속 지켜보겠습니다. 어쩌면 "그리 멀지 않은 미래"에 완료될지 누가 알겠습니까... vscode 외에 저는 사실 Microsoft의 열렬한 팬입니다... 소프트웨어와 하드웨어는 10번 중 9번은 매우 높은 품질의 물건을 만듭니다. . vscode가 9개 중 하나가 되기를 바랄 뿐입니다.

_FastHub를 사용하여 Samsung SM-G950F에서 전송 _

@kamok 모든 새로운 문제는 백로그에 들어가 해결될 때까지 유지됩니다. 이 기능이 전혀 무시되지 않는다고 생각합니다. 당신이 깨닫는 것보다 더 많은 변화가 필요할 뿐입니다. 내가 아는 한 그들은 이것을 확장 API의 일부로 만들고 싶어하며 현재 파일 트리에는 이를 가능하게 하는 기능이 많이 부족합니다.

엄지손가락으로 문제를 정렬하면 이 문제가 두 번째로 인기 있는 문제이고 첫 번째 문제가 작업 중이며 거의 완료되었음을 알 수 있습니다. 나는 그들이 다른 하나가 완료되는 즉시 이 작업을 시작할 것이라고 확신합니다.

이 스레드에 대한 가끔 업데이트는 좋을 것입니다.

원자에서 전환되었지만 업데이트된 파일을 강조 표시하지 않은 대규모 프로젝트에서는 작업하기가 어렵습니다.
이 기능을 사용할 수 있을 때까지 Atom으로 다시 전환

나에게 도움이 되는 대안/임시 솔루션은 "편집기 열기" 보기에서 트리 구조를 복제하는 것이라고 언급할 가치가 있습니다. 일반적으로 보기에는 "업데이트된" 파일이 표시되지만 프로젝트에서 이러한 파일이 있는 위치가 명확한 경우와 달리 파일 이름이 덤프되어 작업하기가 더 어렵습니다.

이에 대한 업데이트가 있습니까?

https://www.youtube.com/watch?v=rTyN-vvFIkE&t=4s

나는 마조히즘적 👎 내 자신의 의견입니다.

VSCode를 계속 시도하고 있지만 이 기능이 없기 때문에 전환할 수 없습니다. 전환을 시도할 때까지 Atom의 이 기능에 얼마나 의존하는지 몰랐습니다.

이것이 원자에서 VS 코드로 전환되기를 기다리면 곧 구현되기를 바랍니다.

+1

2년이 지났다。。。

놀랍게도 귀하의 의견은 그것을 변경하지 않았습니다. 개발 및 잠재적 기여에 관심이 있는 사람들은 이 문제 스레드를 구독하고, 귀하의 의견은 아무런 도움이 되지 않았고 99명에게 쓸모없는 이메일을 보냅니다.

야, 노력하지 않으면 결과가 나오지 않잖아, 그렇지?

처음에는 많이 놓쳤는데 있으면 매우 편리하겠지만 'diff explorer'(세로 메뉴의 세 번째 아이콘)는 정말 강력하고 매우 유용합니다.

+1
구현하면 대박일텐데...!

해킹 설치를 단순화하는 꿀꺽꿀꺽 작업을 작성했습니다(VS Code 1.15만 해당).

git clone https://github.com/karabaja4/vscode-explorer-git-status.git
cd vscode-explorer-git-status
npm install
gulp install # as root/administrator

PS 아직 모든 플랫폼에서 테스트되지 않았습니다. 누군가 OSX에서 사용해 주시면 감사하겠습니다.

@ karabaja4 '해킹'이 vscode 자체에 구현하기가 그렇게 복잡하지 않은 것 같습니다. vscode 개발자가 곧 이 문제를 수정하지 않는 것 같으므로 끌어오기 요청을 생성할 수 있습니까?

@karabaja4 감사합니다! macOS Sierra, VSCode 1.15.1에서 저를 위해 일하고 있습니다.

@karabaja4 감사합니다! 여기에서 Fedora 26, VSCode 1.15.0에서 작업합니다. 그것만으로도 Atom에서 전환하는 것이 훨씬 더 편리해졌습니다.

@karabaja4 +1 감사합니다!! Ubuntu 14.04 64, VSCode 1.15.1(수동 설치)에서 저를 위해 일하고 있습니다.

+1

@karabaja4 +1 굉장합니다.

+1

@매티 플러스 원

_FastHub를 사용하여 arm64 용 HTC MSM8996에서

@ibrokemypie 빼기 2

Lolbug를 사용하여 arm32용 HTC MKB826262에서 보냈습니다.

이 기능에 대한 소식이 있습니까?

+1

+1

+1

@karabaja4 THANKS man =D <3

+1

와우 이건 2년 전에 구현했어야 했어

@eosrei +1

+1

+1
현실을 직시하자. 나는 VSCode를 좋아하지만 Git 탭은 정말 짜증납니다.

@karabaja4 안녕하세요, 1.16이 출시되었습니다. 이번 릴리스에서 해킹을 이식하시겠습니까? 감사 해요.

편집: 1.16에서 작동하지만 다중 루트 작업 공간을 사용할 때는 작동하지 않습니다.

@ 카라 바자

@karabaja4님이 오늘 하루를

+1

+1

+1 댓글은 GitHub 문제에 대한 자동 차단이어야 합니다...

GitHub가 +1 게시물을 구문 분석하고 원본 게시물에 대한 엄지 손가락 이모티콘 반응으로 자동으로 대체하면 더 좋을 것입니다.

@karabaja4 귀하의 해킹은 OSX 10.12.6에서 실행됩니다 - 굉장합니다! 감사합니다.

git clone https://github.com/karabaja4/vscode-explorer-git-status.git
cd vscode-explorer-git-status
npm install
gulp install # as root/administrator

유일한 것은 이제 부팅 시 경고 메시지 가 표시된다는 것입니다. 다행히 경고일 뿐입니다.

VSCode 버전 1.16.0

+1

이것이 아직 구현되지 않은 이유가 있습니까? 아니면 이 기능이 추가될 일정이 있습니까?

어제 나는 Atom의 최신 ide 업데이트를 사용하기 위해 한 시간 동안 다시 갔고 파일 트리 보기에서 컬러 파일을 사용하면 내 인생이 너무 쉽다고 생각했습니다.

편집: 방금 해결 방법을 찾았습니다. vs 코드 파일 중 하나에 한 줄을 추가하는 것(< 1분 노력)은 매력처럼 작동합니다! https://github.com/karabaja4/vscode-explorer-git-status

@timc13 @fro3clr @WLLR9505 @ngortheone @edokeh @ncnegoleo @loehx @aecorredor @BenGale

+1 를 게시하는 대신 이모티콘 반응을 사용할 수 있다는 것을 본 적이 있습니까?

github에 댓글을 올릴 때마다 해당 주제의 모든 구독자는 알림을 받고 일부 사용자도 이메일을 받습니다. +1 쓰여진 이메일을 읽는 것은 일종의 좌절감입니다. 그리고 당신은 그 댓글에서 많은 것을 볼 수 있습니다:-1:.

커뮤니티는 우리 모두가 대신 반응을 사용하기 시작하면 감사하게 생각합니다.
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

이 정보로 인해 불쾌감을 드린 점과 이 알림을 받는 다른 사람들에게 사과드립니다.

다른 스레드에서 Microsoft가 +1 댓글 수로 기능의 우선 순위를 평가했다는 것을 읽었습니다. 내가 이것을 잘못했고 어떤 식으로든 기능의 순위가 매겨지는 방식이 아니라면 사과드립니다. 내 댓글을 삭제했습니다. 어느 쪽이든, 공격적인 태도는 무엇입니까? 같은 걸 더 좋은 톤으로 지적했을 수도 있어요 @leocaseiro

건배.

@aecorredor 안녕하세요, 무례하게 들렸다면 사과드립니다.
저는 영어가 모국어가 아니며 번역된 표현 중 하나가 좋지 않게 들릴 수 있습니다. 댓글에 대한 설명을 개선할 수 있도록 도와주세요. 짜증난다는 말을 바꿔야 하나? 쓸모없는? 감사 해요.

추신: 내가 무례하게 들릴 수 있기 때문에 내 이메일에서 읽은 세상을 편집해 주셔서 기쁩니다. 하지만 누군가를 불쾌하게 할 의도는 없었습니다.

업데이트: 이전 댓글을 교체했습니다. 더 나은 소리가 들리면 알려주세요. 감사 해요

안녕하세요 @leocaseiro ,

처음에 그런 나쁜 말을 써서 죄송합니다. 나는 실제로 깨달았다.
언어 장벽이 아마도 혼란을 일으킨 원인이었을 것입니다. 하지만
예, 나는 그 두 단어를 다음과 같은 라인을 따라 더 많은 것으로 바꿀 것입니다.
"제발, 우리 모두는
공개된 문제/기능 요청, 그리고 사람들이 사용하기 시작했다면 좋을 것입니다.
"+1"과 같은 댓글 대신 이모티콘 반응
스레드에 불필요한 오버헤드가 발생하고 실제로는 그렇지 않은 이메일을 트리거합니다.
의미 있는 방식으로 기여합니다. 방법을 보려면 이 링크를 참조하십시오.
이모티콘 반응 작동: { 여기에 링크 }

건배, 그리고 힘든 감정이 없습니다.

베스트.

2017년 9월 18일 월요일 오후 11시 44분, Leo Caseiro 알림 @github.com
썼다:

안녕하세요 @aecorredor https://github.com/aecorredor , 들리셨다면 사과드립니다.
무례한.
저는 영어 원어민이 아니며 아마도 제 번역본 중 하나일 것입니다.
표정이 안 좋게 들렸다. 에 대한 설명을 개선할 수 있도록 도와주세요.
그 댓글. 짜증난다는 말을 바꿔야 하나? 쓸모없는? 감사 해요.

추신: 제 이메일에서 읽은 세계를 편집해 주셔서 기쁩니다.
무례하게 들렸지만 누군가를 기분 나쁘게 하려는 의도는 결코 없었습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

https://github.com/Microsoft/vscode/blob/master/CONTRIBUTING.md

"+1" 댓글 대신 반응을 사용하세요.

+1

저번 댓글 이후로 +1이 줄어들길 바랐는데 갑자기 또 +1이 떴네요 😁 .

프로그래머는 종종 오류 메시지를 읽지 않고 일부 주석이나 지침을 읽을 수 없다고 사용자를 비난하기 때문에 부끄러운 일입니다.

README.md에 +1 댓글 대신 반응을 사용하도록 사용자에게 요청하는 것이 가치가 있을까요? 아마도 CONTRIBUTING.md에 약간 숨겨져 있을 것입니다.

잘 모르겠습니다. 구독을 취소하고 릴리스 정보가 준비되면 기다리겠습니다.

나는 이것을 처리하는 Gist를 만들었습니다. @karabaja4 의 수정 사항은 무시된 파일/폴더를 제대로 회색으로 표시하지 않습니다(그의 문제 참조). 병합되지 않은 @dseipp 의 PR이 있습니다. 그의 PR에 여전히 문제가 있었기 때문에(단계적 지원이 누락된 것 같습니까?) 그래서 수정했습니다.

따라서 이것이 훨씬 더 잘 작동하도록 하려면 내 요지를 확인하십시오. https://gist.github.com/WadeShuler/1637073371ad126779076344c34278f3

@ikatyang : 죄송합니다. 이 기능이 2017년 10월에 도입된다는 뜻인가요..?

@nkkollaw 링크는 이 댓글에서 가져왔습니다: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

이 의견은 "반복 계획"이 아니라 여기에서 이 문제와 관련된 사항에 대해 논의해 달라는 것이었습니다(영어로 토론해 달라는 요청).

아, 알겠습니다 @tiangolo , 감사합니다.

이 기능을 구현하는 API가 있을 때까지 Atom을 사용하려고 합니다.

프로젝트 자체 내에서 업데이트 작업을 하고 있습니다.
지금은 작동하는 개념 증명을 만들었지만 tslint를 통과하지 못했습니다. 모든 것을 올바른 위치에 배치하기 위해 여전히 레이어를 이해해야 하기 때문입니다.
여기에 약간의 업데이트를 추가하고 누군가가 나를 돕고 싶다면 나중에 내 풀 리퀘스트에 대한 링크를 추가할 것이므로 기꺼이 도와주세요.

2017년 10월 예정 반복!! 👍

우리는 이것의 첫 번째 버전을 가지고 있습니다. 모두가 이것이 10월에 올 것이라고 확신합니다.

조금 더 정보:

• 색상은 테마로 정의되므로 취향에 맞게 조정할 수 있습니다.
• 이것을 활성화/비활성화하는 설정이 있을 것입니다
• 이것은 버전 관리에만 국한되지 않습니다. 우리는 또한 파일 탐색기(#782 참조)에서 오류/경고를 강조 표시하는 방법을 찾고 있으며 이를 확장 프로그램 작성자에게 노출하는 것을 고려하고 있습니다.

열린 질문:

• 색상만 사용하는 것으로 충분합니까? 텍스트 및/또는 아이콘 힌트도 있어야 합니까?
• 부모는 어떤 자녀 상태를 선택해야 합니까? 이것이 중요해야합니까? 오류와 경고가 있으면 쉽지만 변경되거나 추적되지 않거나 무시되는 파일이 더 중요합니까?
• 이러한 파일 장식을 "편집기 열기" 버킷 및/또는 파일 선택기 등에 표시해야 합니까?

일이 진행되는 동안 이 문제를 최신 상태로 유지하겠습니다. 항상 그렇듯이 "+1"-댓글 대신 감정을 사용하세요. 감사하고 행복한 코딩!

개인적으로 위의 이미지로 보는 것만으로도 충분합니다. 멋지고 감사합니다!

짙은 회색에서 .gitignore 가 무시하는 파일이 누락된 것 같습니까?

내부에 무시된 파일에 대한 상위 폴더의 색상(회색)을 변경하지 않습니다. 폴더 자체가 무시되는 경우에만 회색으로 표시됩니다. 내 의견을 참조하거나 몇 가지 의견을 수정하십시오. Git이 상태를 덤프하고 디렉토리인지 파일인지 감지합니다. 파일 트리의 파일/폴더에 클래스를 추가하기만 하면 작동합니다... "git-status-modified" 또는 "git-status-added"와 같이. 그러면 테마가 마법을 발휘할 수 있습니다.

여러분이 작업한 내용을 가져와서 가지고 놀 수 있고 PR을 만들 수 있다면 좋을 것입니다. 솔직히 말해서, 엉망인 경우 합리적인 시간 내에 실행 가능한 솔루션을 얻을 수 없다면 사람들은 코드 사용을 중단할 것입니다. 많은 사람들(저를 포함하여)이 비슷한 문제로 Atom을 떠났습니다.

또한 오류가 있는 경우 트리에서 파일 이름 앞이나 뒤에 점을 사용할 수 있다고 생각합니다. 이것은 눈에 거슬리지 않고 테마가 스타일을 지정하고 Git 색상 강조 표시를 방해하지 않습니다.

예, 이것은 확장 개발자에게 공개되어야 합니다! 이미 수행했어야 합니다. 멋진 확장을 만들거나 여러분이 하지 않은 것을 수정하기 위해 파일 트리를 제어하고 싶지 않은 이유는 무엇입니까?

.gitignore가 짙은 회색으로 무시하는 파일을 놓치는 것 같습니까?

물론 현재 진행 중인 작업이며 한 번에 하나씩 진행됩니다. 무시된 파일은 10월에도 올 것입니다.

여러분이 작업한 내용을 가져와서 가지고 놀 수 있고 PR을 만들 수 있다면 좋을 것입니다.

물론, 모두 joh/feco 분기에 있습니다. 실제 데이터에 제공자를 사용하는 새로운 데코레이션 서비스 가 있습니다. 소비 측에는 파일 이름을 렌더링하는 데 사용하는 파일 레이블이 있습니다.

내부에 무시된 파일에 대한 상위 폴더의 색상(회색)을 변경하지 않습니다. 폴더 자체가 무시되는 경우에만 회색으로 표시됩니다. 내 의견을 참조하거나 몇 가지 의견을 수정하십시오.

"무시된 파일과 해당 자식(있는 경우)이 회색으로 표시됨"이 매우 명확하다고 생각합니다.

@nkkollaw 무슨 소리야?!

@jrieken에서 다음과

“Which child status should a parent pick up? Should this go by importance? That's easy with errors and warnings buts what's more important, a changed, an untracked, or an ignored file?“

그는 무시된 파일이 상위 폴더 상태에 영향을 미칠 수 있음을 나타냈으며, 이는 그렇게 해서는 안 됩니다!

귀하의 수동적 공격적 메시지는 도움이 되지 않는 메시지로 이 스레드를 막고 있습니다...

@WadeShuler : _당신_이 무슨 말을 하는지 모르겠습니다.

나는 방금 무시된 파일과 그 자식이 회색으로 표시되어야 한다고 지적했으며 이 정의가 무시된 파일의 부모가 회색으로 표시되도록 요구하지 않는다는 것이 매우 분명합니다.

에 관해서:

귀하의 수동적 공격적 메시지는 도움이 되지 않는 메시지로 이 스레드를 막고 있습니다...

내 메시지가 어떻게 수동적 공격적인지는 모릅니다. 무슨 뜻인지 모르실 것 같습니다. 하지만 내 메시지 뒤에 댓글을 남긴 유일한 사람이기 때문에 이 스레드를 막고 있는 건 바로 당신입니다.

기이 한.

와.. 좋은 생각! 좋아요!

오른쪽 열에 단일 문자 텍스트 힌트와 같은 xcode를 갖고 싶습니다. 파일을 시각적으로 필터링/추적하기 쉽게 만듭니다.

@nkkollaw 내가 말했다 :

내부에 무시된 파일에 대한 상위 폴더의 색상(회색)을 변경하지 않습니다. 폴더 자체가 무시되는 경우에만 회색으로 표시됩니다.

분명히, 나는 하위 폴더가 아니라 상위 폴더에 대해 이야기하고 있습니다. 여기, 나는 당신에게 그림을 그렸습니다 :

다음은 상위 디렉토리의 .gitignore web 입니다. 참고로

/index.php
/index-test.php
!/assets/css
!/assets/fonts
!/assets/js
!/assets/themes
/assets/*

내 메시지는 WIP에 대한 @jrieken 의 응답에 대한 응답이었습니다. 여기 에서 그는 다음과 같이 말했습니다.

부모는 어떤 자녀 상태를 선택해야 합니까? 이것이 중요해야합니까? 오류와 경고가 있으면 쉽지만 변경되거나 추적되지 않거나 무시되는 파일이 더 중요합니까?

"무시된" 파일/폴더의 상위 항목이 상태를 가질 수 있음을 나타냅니다. 따라서 내 대답. 시각적으로 보이는 것과 Git이 실제로 사용하는 무시 목록을 혼동합니다.

➜  yii2-mlm git:(master) ✗ git status --short --ignored
 M backend/views/layouts/_left.php                   <-- Modified File
?? backend/controllers/PayoutController.php         <-- Added File
?? backend/views/payout/                            <-- Added Directory
?? common/models/Payout.php                         <-- Added File

!! backend/runtime/logs/                            <-- Ignored Directory (everything inside)
!! backend/web/assets/6f57f06b/                     <-- *special rule - Ignored Directory (everything inside)
!! backend/web/assets/9e65c758/                     <-- *special rule - Ignored Directory (everything inside)
!! backend/web/assets/1ecaa825/                     <-- *special rule - Ignored Directory (everything inside)

!! node_modules/                                    <-- Ignored Directory (everything inside)
!! vendor/                                          <-- Ignored Directory (everything inside)

*special rule 는 .gitignore 에 특별한 규칙으로 정의되어 있음을 의미하므로 backend/web/assets/ 가 아닌 임의의 자산 디렉토리입니다. 내용이 무시되는 디렉토리를 처리할 때 무시된 모든 파일을 지정하지 않습니다. vendor 또는 node_modules 디렉토리와 같은. git status 무시 항목에는 항목이 하나만 있습니다.

파일 트리에서, 당신의 클래스를 추가 할 필요가 git-status-ignored 로 시작하는 모든 요소 (파일 및 폴더)에 backend/web/assets/6f57f06b/ .

파일 트리 폴더 backend/web/assets/6f57f06b/ 와 일치하는 CSS는 다음과 같습니다(현재 2개의 규칙이 필요합니다!).

#workbench\.view\.explorer .explorer-folders-view .monaco-tree .monaco-tree-rows .monaco-tree-row .explorer-item[title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" i] {
    opacity: 0.4 !important;
}

그리고

#workbench\.view\.explorer .explorer-folders-view .monaco-tree .monaco-tree-rows .monaco-tree-row .explorer-item[title^="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b/" i] {
    opacity: 0.4 !important;
}

주의: 첫 번째 규칙에서는 = 기호가 있는 제목만 일치하므로 정확히 일치합니다! 두 번째 규칙에서는 모든 제목을 ^= 일치시키므로 문자열의 시작 부분에서 그보다 더 깊은 모든 것(모든 자식)과 일치시킵니다.

디렉토리를 일치시키려면 2개의 CSS 규칙이 필요합니다. 그래서 이 작업을 수행하는 동안 디렉토리에 대한 HTML 요소에 title 를 만들고 후행 슬래시를 포함해야 한다고 생각합니다. 이 스크린샷에서 내가 말하는 내용을 볼 수 있습니다.

예, 귀하의 댓글은 실제로 말을 하지 않고 무례하거나 얄밉거나 엉터리로 행동했기 때문에 수동적 공격적이었습니다. 게다가 당신은 틀렸습니다. 아무도 아이들에 대해 아무 말도 하지 않았고, 심지어 우리가 이야기한 내용도 아닙니다.

@jrieken
Atom 설정이 작동하는 방식: "편집됨"이 "추가됨"보다 우선합니다. 파일을 삭제해도 상태가 표시되지 않습니다. "단계적"에 대한 상태가 없습니다. 나는 다른 사람들이 그들의 Atom 설정을 확인하고 이것이 그들에게도 해당되는지, 그리고 그것이 단지 나의 설정이 아닌지 확인해야 한다고 생각합니다. 모든 상황에 대한 코드를 추가하고 사용자가 원하는 대로 작동하도록 수정하는 것이 좋습니다.

여러 클래스를 추가할 수 있으므로 상위 디렉토리에는 "git-status-added" 및 "git status-modified"가 있습니다. "git-status-deleted" 아래에 무언가가 삭제된 경우 던지기도 합니다.

그런 다음 CSS를 사용하여 일치시키십시오. .git-status-added.git-status-modified 대해 다른 색상을 원하면 녹색 밑줄이 있는 주황색 글꼴을 사용할 수 있습니다(수정된 경우 주황색, 추가된 경우 녹색). .git-status-added 클래스

클래스를 추가하면 모든 사람이 원하는 대로 CSS를 채울 수 있습니다. 그래도 기본적으로 "아주 좋은" 기본 설정을 원할 것입니다.

시간이 나면 그 가지를 뽑아서 확인해 보겠습니다.

린트 오류 및 자식 상태를 처리하는 방법은 무엇입니까?

Atom은 여기에서 볼 수 있는 것처럼 파일 이름 아래에 빨간색 구불구불한 선을 넣습니다.

lint-error 와 같은 클래스를 git 상태와 동일한 요소에 추가해야 한다고 생각합니다. 이 요소는 우리(및 테마)가 자체 스타일시트를 통해 재정의할 수 있습니다.

따라서 위의 예(backend/web/assets/6f57f06b)에서 사용한 것과 같은 파일 트리의 동일한 요소에 대한 div:

<div class="monaco-icon-label folder-icon 6f57f06b-name-folder-icon explorer-item" title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" style="display: block;"> </div>

git-status-edited 와 lint-error 의 자식 상태를 모두 적용하면 다음과 같이 보일 것입니다.

<div class="monaco-icon-label folder-icon 6f57f06b-name-folder-icon explorer-item git-status-edited lint-error" title="/Applications/XAMPP/xamppfiles/htdocs/yii2-mbn/backend/web/assets/6f57f06b" style="display: block;"> </div>

그런 다음 CSS를 통해 일치시킬 수 있습니다.

.folder-icon.explorer-item.git-status-edited {
    color: #cbcb41;  // yellow
}

// Adds a squiggly red line under the filename in the left tree-view list
.folder-icon.explorer-item.lint-error a.label-name {
    background-image: linear-gradient(45deg, transparent 65%, #cc3e44 80%, transparent 90%), linear-gradient(135deg, transparent 5%, #cc3e44 15%, transparent 25%), linear-gradient(135deg, transparent 45%, #cc3e44 55%, transparent 65%), linear-gradient(45deg, 
    transparent 25%, #cc3e44 35%, transparent 50%);
    background-size: 8px 2px;
    background-repeat: repeat-x;
    background-position: left bottom;
}

여러분 슬랙이 있나요? 커밋에 수정된 파일이 많이 있습니다. 파일 트리에 자식 상태 색상을 적용하는 위치를 정확히 찾고 있습니다. /extensions/git/src/repository.ts에 있습니까?

모든 사람에게 감사하고 변경 규칙, 추적되지 않은 파일 및 무시된 파일을 명확히 해주셔서 감사합니다. 내일 내부자들은 이것의 초기 버전과 함께 배송될 것입니다.

몇 가지

• 기본적으로 색상과 가방의 조합이 있습니다.
  
  
  
  • "explorer.decorations.badges": true|false 아이콘 활성화/비활성화
  
  
  • "explorer.decorations.colors": true|false 색상 활성화/비활성화
  
  
• 파일 트리, 열린 편집기 섹션 및 SCM 뷰렛에 색상이 표시됩니다.
• 처음에는 세 가지 색상이 있습니다. workbench.colorCustomizations -설정에서 사용자 지정할 수 있습니다. 색상은 gitDecoration.modifiedResourceForeground .
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground ,
  gitDecoration.conflictingResourceForeground
• 가능성이 변경됩니다 설정 등의 이름을 참고 새 설정은 다른 설정을 다시 제거 될 수 있습니다 추가 될 수 있습니다.

참고 - 초기 게시물 이후에 변경된 사항을 반영하도록 수정됨

부모 디렉토리에 오른쪽 아이콘을 적용하지 않는 것이 더 낫다고 생각합니다. 최소한 옵션이 있을 수 있습니다.

이것은 scm.fileDecorations.useIcons 및 scm.fileDecorations.useColors 가 아이콘과 색상을 모두 제공하는 scm.fileDecorations.enabled 로 바뀌면서 내부자 버전에서 업데이트된 것 같습니다.

아이콘이 아닌 색상만 갖고 싶습니다. IE scm.fileDecorations.useIcons : false 및 scm.fileDecorations.useColors : true 의 "이전" 동작

explorer.decorations.badges 및 explorer.decorations.colors 실험을 시도했지만 효과가 없는 것 같습니다.

편집하다:
Windows 10에서 버전 1.18 내부자, 커밋 f1ee80be081b0d...를 실행 중입니다.
(정보 대화 상자의 텍스트가 강조 표시되어 복사할 수 있으면 좋을 것입니다.)

함께 해주셔서 감사합니다

몇 가지 생각을 했습니다.

• 선택한 색상이 상태 색상 대신 여전히 오래된 회색인 것 같습니다.
• 아이콘이 있는지 여부에 대한 옵션에 동의했습니다( @FredrikFolkesson 기준 ).
• 아이콘이 표시된 상태에서 수정/업데이트된 색상이 밝으면 'M' 또는 'U'가 어두워야(또는 그 반대로) 대비가 있어 읽기 쉽습니다.

색상을 얻기 위해 각 빌드에서 main.js 파일을 업데이트하지 않아도 되기를 기대합니다!!!

사소한 문제(저는 10월 16일 현재 최신 내부자를 사용)를 보고합니다. @jrieken : 이 파일이 현재 선택되어 있으면 프로젝트 트리에서 수정된 파일 이름의 색상이 표시되지 않습니다. 여기서 기대하는 것은 파일이 프로젝트 트리에서 선택되었는지 여부에 관계없이 색상이 동일해야 한다는 것입니다(수정된 파일을 나타냄).

제가 해결하고 싶은 또 다른 문제는 프로젝트 트리뿐만 아니라 열려 있는 편집기 섹션에 대한 동일한 색상 코딩입니다. 현재 열려 있는 편집기 섹션에서 수정된 파일과 수정되지 않은 파일을 볼 수 있는 방법이 없습니다. 수정된 파일에 대한 편집기를 빠르게 파악하는 기능은 매우 편리하므로 수정한 파일 사이를 빠르게 이동할 수 있고 현재 수정된 파일의 이름을 기억하려고 할 필요가 없습니다.

이것은 훌륭한 기능이 될 것입니다. Atom에서 VSC를 처음 접했는데 많이 그립습니다.

Atom에서도 이 기능이 누락되었습니다. 이 기능이 포함된 릴리스는 언제 예정되어 있습니까?

마찬가지로, gitignored 파일이 목록에서 너무 눈에 띄고 모든 것과 혼동되기 때문에 가장 중요합니다...

안녕하세요, 배지 전경색(#36246)을 변경하려면 색상 키도 필요합니다.

지속적인 피드백을 보내주신 모든 분들께 감사드립니다. 최근 변경 사항을 반영하기 위해 초기 요약 설명 을 업데이트했습니다. 또한 설정 변경 사항이 다시 로드하지 않고 반영되고 상태 색상이 선택 색상보다 우선하는지 확인했습니다.

기본적으로 우리는 여전히 색상과 배지를 사용합니다. 대부분 두 가지 이유 때문입니다. 모든 사람이 색상이 무엇을 의미하는지 즉시 아는 것은 아니며 배지(도구 설명과 함께)가 있으면 이 자체로 설명할 수 있습니다. 둘째, 실제로 저와 같은 사람들이 이러한 색상을 구별하는 데 어려움을 겪고 있으며 배지는 이를 좀 더 쉽게 사용할 수 있도록 하기 위한 것입니다.

@jrieken 왼쪽 파일 트리 탐색기의 요소에 CSS 클래스가 적용되고 있는지 알려

예: 새 코드 수정이 파일 또는 폴더를 추가된 것으로 표시하면 git-status-added 와 같은 클래스를 추가해야 합니다. 그러면 스타일시트를 통해 색상을 사용자 정의하고 기본 제공되는 내용에 집착하지 않도록 타겟팅할 수 있습니다.

@WadeShuler 우리의 테마/색상 사용자 정의는 CSS에서 직접 작동하지 않지만 우리가 테마 색상 이라고 부르는 것과 함께 작동 editorLineNumber.foreground 와 같은 특정 항목에 이름을 지정하는 간접 참조입니다. 행 번호의 전경색 이름 입니다. 테마는 해당 이름에 색상을 지정하고 편집기는 렌더링할 때 해당 값을 선택합니다. 자세한 배경 정보는 https://code.visualstudio.com/docs/getstarted/theme-color-reference에서 확인하세요.

다음 내부자는 아마도 내일 19일에 무시된 파일( git.color.ignored )에 대한 특별 렌더링이 있을 것이며 색상/배지가 "편집기 열기" 섹션에 표시될 것입니다. 이에 따라 https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695를 업데이트했습니다.

@jrieken 굉장합니다! git 배지 전경의 색상 키는 어떻습니까?
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

아주 좋은 작품! 이 기능이 vscode에 제공되는 것을 보니 정말 좋습니다.

현재 구현에서 하위 모듈의 수정된 파일은 수정된 것으로 아직 올바르게 표시되지 않습니다.

다음 예에서:

기본 리포지토리에는 src/components/ 하위 모듈이 포함되어 있습니다. 하위 모듈에서 여러 파일이 수정되었습니다. vscode는 src/components/ 가 수정되었음을 올바르게 보고하지만 하위 모듈에서 변경된 사항은 표시하지 않습니다.

Atom은 수정된 파일을 올바르게 식별합니다.

이 문제는 아마도 https://github.com/Microsoft/vscode/issues/7829 와 관련이 있을 것입니다.

@jrieken 굉장합니다! git 배지 전경의 색상 키는 어떻습니까?

@equinusocio 걱정하지 마세요, 일어날 것입니다. 하지만 약간의 생각이 필요합니다. 10월 예정입니다

@jrieken 감사합니다!. 뭔가 놓쳤습니다. 폴더 아이콘도 수정/추가된 색상을 얻습니까? git이 편집/수정될 때 폴더에 대해 다른 아이콘을 설정하기 위해 아이콘 테마에 추가할 새 키가 있습니까?

@jrieken - 1.18의 문제. 지금까지의 노고에 감사하다는 말을 전하고 싶습니다. 방금 v1.18 Insiders를 테스트했습니다. 위의 스레드를 훑어보았으므로 아래에 언급한 내용을 처리하기 위해 이미 1.19에서 작업 중인 항목이 있는 경우 용서하십시오.

1) 파일 트리의 "추가됨" 상태는 "U" 배지가 있는 "업데이트 및 병합 해제됨"처럼 보입니다. 추가된 파일에는 "A" 배지가 있어야 합니다.

2) git.color.added 대한 색상 옵션이 없습니다.

3) git.color.ignored 에는 색상 옵션이 없습니다.

4) (Glitch) "추가된" 파일을 "추적되지 않은" 파일로 취급합니다. "추가된" 파일을 검사했는데 html에 있는 것처럼 보이지만 추적되지 않은 것으로 생각합니다. ( span 제목은 "untracked"이고 클래스는 "U" 아이콘인 monaco-decorations-style-32 ). 의 색상 변경하는 경우이 분명하다 workbench.colorCustomizations 에 대해 git.color.untracked 가, "추가"파일이 있어야 제어로.

5) "R" 상태 지원, "Renamed" 또는 이동된 경우 "R" 배지를 추가하고 일치하는 git.color.renamed 설정을 추가합니다.

감사합니다 1.19버전 기대하겠습니다 👍

@danjjl #7829에 대한 보류 중인 PR이 있습니다. 이를 적용하면 git 하위 모듈이 채색됩니다.

잠재적인 문제가 있습니다. 하위 모듈이 변경되면 하위 모듈(하위 모듈의 루트인 디렉토리)이 기본 git 저장소의 디렉토리 상태 색상으로 처리되는지 아니면 다른 포함된 파일을 기반으로 색상을 지정합니다.

즉, 하위 모듈 디렉토리의 색상이 상위 디렉토리 또는 하위 모듈의 'git status'를 기반으로 하는지 알 수 없습니다. 어쨌든 중요하지 않을 수 있습니다.

@jrieken 이 문제를 논의할 Slack 그룹이나 다른 곳이 있습니까? 내가 도울 수 있습니다 :) 마스터 브랜치에서 현재 변경 사항을 끌어오고, 개발하고, 디버그할 수 있었습니다. "U"로 표시되는 "추가된" 파일을 수정하고 "단계적" 지원도 추가했습니다. 프로젝트에서 처음 하는 것이기 때문에 마스터로 재설정하고 다시 수행합니다. 나는 많은 변화를 겪었고 핵무기가 아닌 외과 의사처럼 가고 싶습니다.

왜에이 검사입니다 raw.x + raw.y 에 수표 뒤에 raw.x 다음 raw.y ? 2개의 다른 상태와 일치하게 만드는 것 같습니다.

ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED 및 기타 몇 가지에 대해 2개의 상태 상수가 있는 이유는 무엇입니까? 다양한 git 상태를 모두 이해하지만 Git 상태의 이름이 아닌 최종 사용자를 위해 처리하는 것이 좋습니다. ADDED 는 UNTRACKED 로 현재 가지고 있는 것에 사용해야 git.color.added 설정 코드가 됩니다. 나는 이러한 상태 상수 중 몇 가지가 중복되어 단순화되고 정리되어야 한다고 생각합니다.

_M <-- underscore = space/nothing 의 git status 는 raw.y 와 일치하며 INDEX_MODIFIED . 이것은 올바르지 않습니다. x = 없음 및 y = M 가 staged 냅니다.

어떤 이유로 때로는 무작위로 변경 사항을 반영하지 않는 것 같습니다. 또한 git 상태 변경이 위에서 아래로 재귀적으로 스캔하는 것처럼 보입니다. 대규모 프로젝트가 있는 경우 폴더/파일을 통해 "무시됨" 상태가 떨어지는 것을 볼 수 있습니다. 속도를 높이기 위해 더 깊이 탐색하고 해당 디렉토리에 대해 시작하고 회색으로 만드는 것처럼 보였습니다. -- 이 프로세스로 인해 시스템/VSCode가 많이 느려집니까? 벤치마킹한 사람이 있습니까? 부모가 무시될 때 각 파일/폴더를 검색할 필요가 없습니다. 자녀는 부모로부터 신분을 받아야 합니다. -- ignored 파일이 5,000

오늘 나중에 변경 사항을 다시 실행하고 PR을 발행하겠습니다.

작업에 다시 한번 감사드립니다. 헐레벌떡 하는게 아니라 진짜 할 수 있으니까 도와주려고 하는 것 뿐이야 ㅋㅋ 👍

@WadeShuler 나는 그 중 일부에 대답할 수 있습니다. 나는 당신이 repository.ts의 Repository.updateModelState()를 찾고 있다고 가정합니다. raw.x + raw.y 검사를 확인하면 모두 반환되므로 실제로 raw.x 및 raw.y를 수행할 수 없습니다. raw.x와 raw.y가 분리된 이유와 INDEX_*가 있는 이유는 모든 INDEX_*가 스테이징되기 때문입니다. 스테이징된 것만 변경됩니다. INDEX를 STAGE로 바꾸면 그들이 사용하는 논리가 기술적으로 정확하지만 더 합리적이라고 생각합니다. https://git-scm.com/docs/git-status , 특히 "XY 의미" 테이블을 참조
(편집: 와우 형식이 잘못되었습니다. 그냥 원본으로 가십시오. 절반쯤 아래에 빨간색으로 표시된 표입니다.)
그것이 그들이 이 모든 일에 사용하고 있는 것이 분명합니다.

그리고 MODIFIED, Index unmodified(즉, 스테이징되지 않음)와 일치하는 _M 케이스에서 당신이 착각하고 있다고 생각합니다. 물론 다른 곳에서 이 코드의 복제본을 보고 있지 않는 한.

@petkahl 감사합니다. Git Status Short Format에 대해 잘 알고 있습니다. 몇 주 전에 이 문제가 공식적으로 해결될 때까지 기본 Git 상태를 추가하기 위해 vsc git 상태를 수정 하는 데 사용했습니다.

(어쨌든) _M (밑줄 = 공백)을 얻을 수 있습니다. 어떻게, 왜, 언제.. 나는 이것을 오늘 일찍 얻었습니다(몇 주 전에 내 Gist 작업을 할 때):

➜  git-test git:(master) ✗ git status -s --ignored                                  
 M added.php       <-- notice space before M
A  test2.php
?? untracked.php
!! vendor/

이제 몇 시간 후에 실행하고 "A"를 얻습니다. 그 이후로 뭐가 달라졌는지는 모르겠지만..

➜  git-test git:(master) ✗ git status -s --ignored         
A  added.php
A  test2.php
?? untracked.php
!! vendor/

내 Gist에 대한 연구를 할 때 "A_"와 "_M"을 무대에 올릴 수 있다는 결론을 내린 것 같습니다. 나는 또한 git-status 문서보다 훨씬 명확하게 상태를 분류한 사이트를 찾았지만 다시 찾을 수 없습니다.

준비 및 수정된 파일에 대해 "AM"을 얻을 수도 있습니다. 비어 있는 새 파일을 만들고 추가(스테이징)하고 파일을 편집하고 저장하고 상태를 확인합니다.

➜  git-test git:(master) ✗ touch test.php         <--- create file
➜  git-test git:(master) ✗ git add test.php       <--- add/stage
➜  git-test git:(master) ✗ nano test.php          <--- edit, add some text, save
➜  git-test git:(master) ✗ git status -s --ignored
A  added.php
AM test.php              <--- modified after staging
A  test2.php
?? untracked.php
!! vendor/

그러면 "[S][M]"이라는 배지가 2개 있어야 합니까? 어떤 파일을 준비했는지 알고 싶습니다. 체리 따기에 유용합니다. 준비된 파일을 수정했는지 계속 확인하는 것이 유용할 수 있습니다. 최소한 단계적 배지가 있어야 합니다.

@WadeShuler 커밋하고 수정하여 일관되게 _M을 얻을 수 있습니다. 즉, 인덱스에서는 변경되지 않았지만(_=공백) 작업 트리에서는 수정되었습니다.
그래서:
파일 생성: ??
자식 추가 파일 A_
git commit (상태가 아니지만 공간 공간과 동일)
파일 수정: _M
자식 추가 파일 M_
다시 수정: MM

배지가 2개일 때 배지에 대한 의견이 없습니다. 나는 일반 git status 처럼 명확하게 구분되는 상태 창을 보지 않고 체크인하지 않습니다. 우선 순위가 있는 것을 선택할 수 있는 설정일 수도 있습니다. 나는 둘 다에 대한 주장을 볼 수 있었다. 또는 두 개의 배지가 있을 것 같습니다. 착색도 마찬가지겠죠?

Staged 지원을 추가했습니다. WadeShuler/ vscode:gitstatus-fix 에서 변경 사항을 확인할 수 있습니다. 또한 Git 상태 탭의 일부 배지를 조금 더 크게 만들어 보기 좋게 만들었습니다.

어떤 이유로 vendor 디렉토리의 어두워짐/무시를 제거했지만 내부의 내용은 여전히 ​​회색으로 표시되어 무시됩니다. 내 간단한 수정이 vendor 디렉토리를 회색으로 표시하지 않는 이유를 모르겠습니다. 그게 내가 방금 한 일의 유일한 문제이고 내가 아직 PR을 발행하지 않은 이유 ...

준비된 파일 색상/아이콘이 포함될 예정이라면 이것은 확실히 선택 사항이어야 합니다. 개인적으로, 나는 내 목록에 원래의 새/수정된 색상과 다른 색상으로 스테이지된 것을 보고 싶지 않습니다.

staged를 포함하기 시작하면 new/new-staged/modified/modified-staged/modified-staged-modified/new-staged-modified 등의 모든 조합과 순열을 포함할 수 있기 때문에 빠르게 복잡해질 수 있습니다. , 색상과 혼란의 거대한 매트릭스로 이어질 것입니다.

나는 우리가 문제를 너무 복잡하게 만들지 않는 것에 투표합니다.

동의합니다 @dseipp. 이것이 내가 만들 때 초기 해킹에서 준비된 파일에 대한 지원을 병합하지 않은 정확한 이유입니다. 왜냐하면 준비된 파일에 색상을 지정할 필요가 없기 때문입니다.

색상 강조 표시의 목적은 파일 탐색기에서 새 파일/수정된 파일을 한 눈에 찾을 수 있도록 하는 것입니다. 일부 파일을 준비하는 경우 일반적으로 커밋 전이거나 다른 작업이 완료된 경우이므로 정상적으로 색상을 지정할 필요가 없습니다.

가능한 모든 유형의 git 상태에 색상을 추가하면 파일 탐색기가 크리스마스 트리처럼 보이기 시작하고 실제로 무슨 일이 일어나고 있는지 보기가 매우 혼란스러울 것입니다.

@jrieken 최신 내부자에 대한 버그 보고서가 하나 더 있습니다.

• VSCode 버전: 코드 - 내부자 1.18.0-내부자(82dcf9835265cd0a45ec135587ae2a82673f1c8f, 2017-10-20T04:24:25.632Z)
• OS 버전: Windows_NT x64 10.0.15063

기본적으로 VS Code는 때때로 일부 파일이 수정되고 그에 따라 색상이 지정되어야 한다는 사실을 "잊습니다". 예를 들어 현재 수정된 파일이 6개 있습니다. VS 코드(올바르게)는 git 버튼에 숫자 "6"을 표시합니다. 그러나 프로젝트 파일 트리에서 노란색으로 표시된 파일 하나만 보고 나머지 5개 파일은 수정되지 않은 것처럼 보입니다. 흥미롭게도 6개 파일 모두 열려 있는 편집기 섹션에서 적절하게 색상이 지정되어 있습니다.

@dseipp 선택 사항일 수 있습니다. 그러나 파일을 준비할 때까지 "단계적" 색상을 볼 수 없습니다... 따라서 99%의 시간에도 표시되지 않으며 아무도 귀찮게 해서는 안 됩니다.

@karabaja4 나는 그것이 사용되지 않는다는 것에 동의하지 않습니다. 당신은 당신이 결코 사용/주의/단계적 착색이 필요하지 않다는 점을 지적했습니다...

색상 강조 표시의 목적은 파일 탐색기에서 새 파일/수정된 파일을 한 눈에 찾을 수 있도록 하는 것입니다. 일부 파일을 준비하는 경우 일반적으로 커밋 전이거나 다른 작업이 완료된 경우이므로 정상적으로 색상을 지정할 필요가 없습니다.

따라서 이 기능이 추가되어도 문제가 되지 않습니다...

준비된 파일을 볼 수 있으면 커밋하려는 항목을 선택하는 데 도움이 됩니다. 100개의 파일이 변경되어 그룹화해야 하는 경우 파일 트리를 탐색하고 준비된 항목을 쉽게 확인하고 놓친 파일을 잡아 동일한 커밋에 있는지 확인할 수 있습니다.

몇 번이나 몇 개의 파일을 커밋했는데 하나를 놓쳤다는 것을 깨달았습니까? 그런 다음 2가지 옵션이 있습니다. 누락된 파일을 포함하도록 마지막 커밋을 수정하거나 새 커밋을 만듭니다. 팀과 함께 작업할 때 동일한 커밋에 두는 것이 더 명확하고 덜 혼란스럽습니다.

준비된 시점에서 파일이 추가, 수정 또는 기타 다른 것이 있는지 여부는 중요하지 않습니다.

솔직히 말해서 Visual Studio Code가 Git을 처리하는 방식은 복잡하고 버그가 많습니다. 큰 파일 트리, 말 그대로 파일/폴더를 통해 색상이 떨어지는 것을 볼 수 있습니다. 무작위로 착색을 떨어 뜨립니다 ...

내 생각에 전체 Git 지원 요구 사항은 처음부터 다시 작성해야 합니다.

또한 단계적 파일 색상 지정에 대한 지지를 표명하고 싶습니다(선택 사항은 활성화할 수 있는 한 괜찮습니다).

내 작업 흐름은 다음과 같습니다. 일부 기능/버그 수정 작업을 시작하고 "OKish" 상태로 만듭니다. 즉, 코드가 다소 작동하지만 일부 개선/조정/정리 또는 리팩토링이 필요합니다. 그 순간 나는 나의 변화를 준비한다. 그런 다음 정리 및 리팩토링을 수행합니다. 리팩토링이 실패하거나 너무 지저분해지면 그냥 준비된 상태로 되돌립니다.

현재 수정하고 있는 파일을 볼 수 있는 기능은 매우 유용하며 변경 사항을 준비할 때 모든 정보를 잃어버리고 색상이 없는 일반 트리에 도달하고 싶지 않습니다.

@vvs 색상을 잃지 않는 준비된 파일에 대해 동의합니다. 색상은 커밋될 때까지 유지되어야 합니다. 단계적 색상은 새/수정된 색상을 유지하고 추가 단계적 색상은 선택 사항으로 유지하는 것을 선호합니다.

Staged는 동일한 색상을 유지할 수 있지만 대비를 주기 위해 일종의 하이라이트 또는 굵게 추가합니다.

선행 기술을 보는 것이 도움이 될 수 있습니다 .. 단계적 표시기를 본 기억이 없지만 시간이 변경되었을 수 있습니다.

수정된/미준비된/... 파일에 대한 파일 탐색기의 아이콘이 정말 필요한가요? 나는 주의력에 약간의 문제가 있어서 색상과 아이콘이 나를 매우 쉽게 산만하게 합니다. 선택 사항이며 기본적으로 비활성화될 수 없습니까? 그들에 의해 주의가 산만해지는 것은 나뿐인가?

사용자 경험의 관점에서 볼 때 때로는 더 적은 것이 더 많으며 많은 사람들이 이러한 기능을 비활성화하는 옵션을 찾는 데 신경을 쓰지 않고 계속 고통을 겪거나 심지어 편집자를 변경할 수도 있습니다. 나는 이것을 곰곰이 생각해보고 이것이 더 나은 UX를 위해 정말로 필요한지 결정하는 것이 좋을 것이라고 생각합니다(이 아이콘의 요점이라고 가정합니다.)

* 이 문제에 대한 모든 의견을 읽을 시간이 없었으므로 이미 논의된 사항에 대해 질문하는 경우 알려주세요. 시간을 할애하여 가능한 한 빨리 모든 내용을 읽고 답변을 드리겠습니다. 말한 것. 감사 해요.

나는 이것을 곰곰이 생각해보고 이것이 더 나은 UX를 위해 정말로 필요한지 결정하는 것이 좋을 것이라고 생각합니다(이 아이콘의 요점이라고 가정합니다.)

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308이 기본적으로 색상과 배지가 있는 이유입니다. UI를 좀 더 복잡하게 만들고, 접근 가능하고 포괄적이면서도 매끄럽고 깨끗한 제안을 위해 열려 있다는 데 동의했습니다.

@jrieken 감사합니다! 배지를 도입한 커밋을 알려 주시겠습니까? 나는 두 가지 문제(색을 보는 데 어려움이 있거나 그것이 무엇을 위한 것인지 알지 못하는 문제, 주의를 산만하게 하는 문제)에 모두 도움이 되는 것을 찾으려고 노력할 것입니다.

@jrieken Xcode에서 페이지를 가져와 배지를 더 만들어 보겠습니다.

배지는 초보자에게 힌트를 주는 데 유용하지만 색상을 배운 후에는 어수선해집니다.

추가 자전거 이동을 위해 저는 시각적 중요성이 동일하기 때문에 git.color.ignored (위의 _left_) 색상의 배지를 선호합니다. 즉, 사라지지만 내가 당신을 필요로 할 때 사라지지 마십시오.

미묘한 배지를 구현하는 경우 일관성을 위해 Source Control 사이드바 배지를 업데이트해야 합니다.

배지 토론이 어떤 방향으로 진행되든 배지 디자인은 최소한 Git 사이드바의 디자인과 일치할 수 있습니까? Explorer 사이드바용 디자인과 Git 사이드바용 디자인이 각각 다르다는 것은 다소 엉뚱한 느낌입니다.

@jayjun의 한 글자 제안 이 마음에 듭니다. 오늘 시도해 보겠습니다.

미묘한 배지를 구현하는 경우 일관성을 위해 Source Control 사이드바 배지를 업데이트해야 합니다.

그렇게 될 것입니다, 그것은 10월에 대한 나의 계획에 있습니다.

https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695를 최신 스크린샷과 색상 이름으로 업데이트했습니다. 또한 내일 내부자와 함께 SCM 뷰렛에 동일한 배지를 표시하지만 색상 레이블은 표시하지 않습니다. 그렇게

더 좋아 보입니다 @jrieken - 지속적인 노력에 감사드립니다. 뱃지가 훨씬 더 예쁜 것 같아요!

배지가 U 이어야 합니까? 나는 지역 사회에 무게한다고 생각합니다. U 내가 먼저 생각하게 updated . Git 용어로 untracked 라는 것을 알고 있지만 U 가 추적되지 않는 기본 용어에 익숙하지 않은 사람들에게 특히 A 가 더 적합하다고 생각합니다. - 저는 개인적으로 추가된 A 에 투표합니다. 마찬가지로 저장소에 추가되었습니다.

그런 다음 staged (설정을 통한 선택 사항)에 대한 지원과 거의 비슷합니다 👍

@WadeShuler ,

편집: 하지만 U가 혼란스러울 수 있다는 데 동의합니다.

물음표로 해도 괜찮을 것 같아요. 그러나 나는 코드를 생각하지 않는다.
Git만 지원합니까? 시각적으로 봐야 한다고 생각하지 않는다.
편집기는 "Git"이지만 일반적으로 더 많은 버전 제어가 가능합니다.

어쨌든 나는 "U"를 좋아하지 않는다 lol

2017년 10월 24일 화요일 오후 2시 20분 Peter Kahle [email protected]
썼다:

@WadeShuler https://github.com/wadeshuler , 물음표는 어떻습니까
(?) 추적되지 않은? 나는 A가 다른 의미를 가지고 있기 때문에 A를 좋아하지 않는다.
적어도 내 마음에는 여기에서 의미하는 것보다 git이 더 중요합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

공평하게, 불가지론적이어야 합니다. 그러나 "버전 관리 시스템에 알려지지 않음"으로 ? 나에게 의미가있다. 그러나 N(신규용)도 작동할 수 있으며, 다른 사람이 그럴 것이라고 확신하지만 그에 대한 과부하가 생각나지 않습니다.

네, @jrieken 님 의 노력에 감사드립니다! 정말 잘보고 있습니다! 미묘한 뱃지가 플러스입니다.

저는 @WadeShuler 및 @petkahl 과 함께 U를 다른 것으로 바꾸고

이것이 함께 오는 것을보고 흥분됩니다!

workbench.colorCustomizations.git.color.ignored 이 모든 사람에게 효과가 있습니까?
오늘 1.18.0-insider 마지막으로 업데이트되었으며 무시된 색상이 여전히 선택되지 않습니다. 또한 "_deleted_" 및 "_conflict_"가 아직 작동하지 않는 것 같습니다... 아마도 내일 업데이트로,
그러나 나를 괴롭히는 것은 무시된 색상입니다. 파일 이름은 버전이 지정된 수정되지 않은 파일과 동일하게 보입니다. 즉, 특별한 색상이 적용되지 않습니다.
참고: 스크린샷의 저장소에는 추적된 파일이 전혀 없습니다. 모든 파일은 추적되지 않습니다. .gitignore 에서 "_shared.module.ts_"를 제거하면 갈색으로 표시됩니다(내 추적되지 않은 색상 설정).

그래도 배지는 U여야 합니까? 나는 커뮤니티가 무게를 실어야 한다고 생각합니다. U는 나를 가장 먼저 업데이트된 것으로 생각하게 만듭니다. 나는 그것이 Git 용어로 추적되지 않는다는 것을 알고 있습니다.

우리는 이전에 'U'를 사용해 왔으며 이것이 더 나은 것을 논의하기 위한 올바른 문제는 아니지만 git 사용자는 용어를 알고 다른 SCM 공급자의 경우 다른 문자/아이콘을 사용할 수/사용해야 한다고 생각합니다(오늘날의 경우입니다).

이 기능은 추가되지 않았으며 이후로 이 스레드에서 활동했습니다.
앞으로 나아가기 시작했습니다. 나는 처음부터 "U"배지를 언급했습니다.

이 스레드는 전체 기능을 개발하고 다듬는 것에 관한 것입니다.
이것은 새롭다. 글꼴 색상, 배지 스타일 및 배지 색상이 모두 허용되는 경우
이 스레드에서 논의하려면 편지도 마찬가지입니다.

그렇다면 이 스레드 이외의 다른 곳에서 "U"를 사용하고 있습니까?

그렇다면 이 스레드 이외의 다른 곳에서 "U"를 사용하고 있습니까?

내부자가 아닌 안정적인 상태를 확인하고 git으로 SCM 뷰렛을 확인하세요. 그것은 유 파일을 ntracked에 대한 U를 사용합니다.

@WadeShuler @jrieken 현재 SCM 뷰렛(1.17.2)은 _untracked file_을 회색 U로 표시하고 _added file_을 녹색 A로 표시 합니다. git status 는 _추가된(준비된) 파일_을 ANSI 녹색으로 표시 합니다.

따라서 _추적되지 않은 파일_에 대해 녹색 U 로 표시된 혼란을 이해합니다. 나는 또한 녹색 U 와 녹색 A가 섞여서 내 눈이 아플 것입니다.

Atom은 추적되지 않은 새 파일과 준비된 새 파일을 모두 녹색 으로 지정하고 Xcode는 새 파일인 한 추가된 파일을 A 로 표시합니다. 둘 다 나를 조금도 괴롭히지 않았습니다 (그러나 녹색 U는 그렇습니다).

따라서 추적되지 않은 _및_ 준비된 새 파일에 대해 녹색 A 를 사용하겠습니다.

계속 'U' 대 'A' 대 '?' https://github.com/Microsoft/vscode/issues/36912의 토론

나는 동의한다. 오늘날 인터페이스에서 사용되는 문자를 계속 사용하는 것이 더 낫다고 생각합니다. 나도 'U'를 좋아하지 않지만 이것은 이 기능 요청의 범위를 벗어난 것 같습니다. 이것이 변경되면 전체 프로그램에서 변경되어야 합니다.

좋아, 이것은 거대한 스레드이고 나는 단지 그것을 훑어볼 시간이 있다. 그래서 나는 단지 여기에서 말할 것이다: 이것을 비활성화하는 설정이 있기를 바랍니다. 나는 모든 파일 이름을 같은 색상으로 지정하는 것을 선호하며 상태를 확인해야 할 때 git status 합니다. :-)

이 제품은 버려졌나요? 것 같다.

현재 list.activeSelectionForeground 가 git status 스타일링보다 우선하는 것 같아서 git status 색상이 선택된 파일을 볼 수 없습니다. 이 정보는 현재 선택한 파일에서도 유용하다고 생각합니다. explorer.decorations.colors 가 true
이 동작은 내부자 1.18 8dfa696에서 관찰되었습니다.

현재 list.activeSelectionForeground가 git status 스타일링보다 우선하는 것 같아서 git status 색상은 선택한 파일을 볼 수 없습니다.

실제로 최신 내부자에서도 마찬가지입니다(방금 업데이트됨). 프로젝트 트리에서 파일 이름을 클릭하면 파일 항목의 색상이 변경됩니다(예: 노란색/수정됨에서 중립으로). 또한 이것은 다소 혼란스러운 행동이라고 생각합니다. 사용자가 파일을 클릭할 때 파일의 색상이 변경되지 않아야 합니다.

Btw, 열린 파일 목록과 동일한 문제입니다. 거기에 있는 파일을 클릭하면 자식 상태 색상이 중립 선택 색상으로 바뀝니다.

Btw, 열린 파일 목록과 동일한 문제입니다. 거기에 있는 파일을 클릭하면 자식 상태 색상이 중립 선택 색상으로 바뀝니다.

뭐, 선택의 배경색이 장식색과 충돌하는 경우가 많기 때문에 일부러 그렇게 한 것입니다. git.untrackedSelectedForeground 및 git.untrackedFocusedForeground 와 같은 색상을 추가하는 것은 그다지 매력적이지 않은 것 같습니다. 따라서 항목이 선택 되고 포커스가 있을 때 선택 색상이 승리하도록 합니다.

아톰은 문제가 없는듯....

새로운 설정이 필요하지 않습니다... 선택한 항목의 배경색이 간섭하는 경우 테마가 업데이트됩니다. 그렇게 하지 않는 사람들은 커뮤니티에서 해당 테마를 사용하지 않기로 결정할 것입니다.

나는 확인하지 않았지만 "배지"(즉, U, M)가 여전히 svg 파일이 아니기를 바랍니다. 스타일/색상을 지정할 수 있는 원시 텍스트여야 합니다.

솔직히 VSCode는 투박한 구성 설정 대신 이러한 것들을 위한 스타일시트를 사용했어야 했습니다. 다소 단순한 프로세스를 지나치게 복잡하게 만들었습니다.

@WadeShuler 선택과 초점이 ​​있고 스크린샷에 편집기 커서가 있기 때문에 항목이 선택 맞지 않는다고 생각합니다. 사실 나는 Atom에서 선택과 집중의 차이를 보지 못합니다. 이것이 VS 코드의 방식입니다.

선택되었지만 집중되지 않음

선택 및 집중

@jrieken 나는 두 번 확인했고 내 Atom에서 선택 대 집중이 동일한 결과를 생성합니다. 왼쪽 파일 탐색기 창에서 yellow 글꼴 색상을 잃지 않습니다. 두 번째 스크린샷에서 red 색상이 test.foo 에서 손실된 것이 문제입니다.

기본 어둡고 밝은 Atom 테마와 약 3개의 다른 테마를 사용해 보았습니다. 내 기본값(SS에서 볼 수 있듯이)은 Seti(UI와 테마 모두)입니다. 내가 무엇을 하든 Atom이 파일 탐색기에서 yellow 색상을 삭제하도록 할 수 없습니다. 아톰 버전 1.21.2.

선택된

선택 및 집중

기본적으로 VS Code는 선택되거나 집중된 상태에 관계없이 git 상태 색상을 유지해야 합니다.

당신의 문제가 테마라면 그것은 당신의 문제가 아닙니다. 업데이트하고 수용하는 것은 테마 개발자의 책임입니다.

참고 사항: 최신 내부자를 확인하거나 코드를 보지 않았지만 git ignored 파일은 글꼴 색상이 아닌 opacity 사용해야 하므로 항상 x 색상에 관계없이 일반 파일보다 어둡습니다.

@WadeShuler 테마 관리자가 비즈니스를 처리하는 방법에 대한 피드백에 감사드립니다! VSCode 팀이 감히 그렇게 하는 데 도움이 되는 API를 제공할 수 있습니까? 게으른 개발자들!

@fernandofleury 아무도 테마 관리자를 관리하기 위한 API를 제공하지 않는 것에 대해 아무 말도 하지 않았습니다. 내 게시물은 그런 종류의 것을 말하지 않았습니다. 따라서 귀하의 냉소적 인 의견은 단순히 유효하지 않으며 정당하지 않습니다.

@jrieken이 말했습니다.

뭐, 선택의 배경색이 장식색과 충돌하는 경우가 많기 때문에 일부러 그렇게 한 것입니다.

나는 말했다:

당신의 문제가 테마라면 그것은 당신의 문제가 아닙니다. 업데이트하고 수용하는 것은 테마 개발자의 책임입니다.

문제는 파일/폴더 트리 항목(일반, 선택, 집중)의 전경(실제로는 배경색) 색상과 다양한 git 상태에 대한 글꼴 색상 선택 간의 충돌입니다.

이것은 테마 개발자의 책임 _일 것입니다_. 충돌하지 않도록 트리 항목의 전경색 과 다양한 자식 상태의 글꼴 색을 모두 선택해야 합니다.

예: 테마 개발자가 ThemeX를 가지고 있고 탐색기 파일 트리의 항목에 대한 글꼴 색상은 yellow 입니다. 글쎄, 그의 기본 글꼴 색상은 기본 yellow git 상태 색상과 충돌합니다. 어떤 파일이 수정되었는지 더 이상 알 수 없습니다. 따라서 이것은 테마 개발자의 책임이 될 것입니다! -- 익스플로러 파일 트리에서 선택/선택에 초점을 맞춘 항목의 배경색과 git 상태의 글꼴 색상도 마찬가지입니다.

지금 연기된 건가요?

@IljaDaderko 다음 Stable 버전의 곧 출시 될

@IljaDaderko VSCode v1.18 은 이미 출시 되었으며 여기에 설명된 변경 사항이 포함되어 있습니다.

무시된 파일 색상은 v1.18 업데이트의 일부로 간주됩니까? 문서에는 gitDecoration.ignoredResourceForeground 를 사용하여 무시된 파일에 색상을 지정할 수 있다고 나와 있지만, 지금까지 그 영향을 전혀 볼 수 없었습니다. 수정/추적되지 않은 채색은 훌륭하게 작동합니다. 이것은 안정적인 1.18.0, Windows에 있습니다.

여기에서도 동일합니다(무시된 색상에 대해). 이 전체 Git 구현이 시작된 이후로 저에게도 효과가 없었습니다. 내부자를 사용합니다.
gitDecoration.ignoredResourceForeground 가 하는 모든 일은 무시된 파일을 색칠에서 무시하는 것입니다. :)

그것은 나를 위해 일하고 그것은 장관처럼 보입니다.

드디어 왔어요 🥇

@arxpoetica 이것은 내가 얻은 것입니다 :

어떤 사람에게는 효과가 있고 다른 사람에게는 효과가 없을 수 있습니다. 이해가 되지 않습니다. gitDecoration.ignoredResourceForeground 설정하는 것뿐입니다.
저만 효과가 없는건가요? 정말 아무도 없어요? :) 아, 그리고 @Shurelia
다른 사람(우리, 사용자)이 작동한다고 말하기 전에 무시된 색상 설정을 실제로 테스트한 적이 있습니까?

OS: 윈도우 10 프로(1709)
VSCode: 1.19.0-내부자(방금 이전에 업데이트됨)
직장 노트북과 가정용 데스크탑에서도 마찬가지입니다.

내부자에 있습니까? 어떻게 사용할 수 있습니까?

모두 축하합니다!

@nkkollaw 😎 내부 및 안정(1.18) 모두에서

@MrCroft 여기에서 git-ignore 문제에 대해 논의하십시오. https://github.com/Microsoft/vscode/issues/37857

최신 안정적인 빌드에서 이 기능을 제공했으므로 이제 이 문제를 닫고 잠글 시간입니다. 주제 토론 및 버그 보고서를 위해 새 문제를 만드십시오. 이 영역과 관련된 문제는 file-decorations -label로 태그가 지정됩니다.

여러분, 이 기능을 있게 만든 훌륭하고 지속적인 피드백에 감사드립니다!

내 이전 의견 을 요약하고 반복합니다.

몇 가지

• 기본적으로 색상과 가방의 조합이 있습니다.
  
  
  
  • "explorer.decorations.badges": true|false 아이콘 활성화/비활성화
  
  
  • "explorer.decorations.colors": true|false 색상 활성화/비활성화
  
  
• 파일 트리, 열린 편집기 섹션 및 SCM 뷰렛에 색상이 표시됩니다.
• 처음에는 세 가지 색상이 있습니다. workbench.colorCustomizations -설정에서 사용자 지정할 수 있습니다. 색상은 gitDecoration.modifiedResourceForeground .
  gitDecoration.deletedResourceForeground ,
  gitDecoration.untrackedResourceForeground ,
  gitDecoration.ignoredResourceForeground ,
  gitDecoration.conflictingResourceForeground