Vscode: Status Git di File Explorer

Dibuat pada 19 Nov 2015  ·  247Komentar  ·  Sumber: microsoft/vscode

Mirip dengan apa yang disediakan atom di penjelajah proyek:

  1. File baru ditampilkan hijau.
  2. Dimodifikasi ditampilkan kuning/oranye.
  3. File yang diabaikan ditampilkan transparan-ish.

Terima kasih

feature-request file-decorations file-explorer git

Komentar yang paling membantu

Saya menambahkan beberapa tangkapan layar untuk membantu:

Standar atom:

screen shot 2016-12-15 at 12 29 11

Standar VSCode:

screen shot 2017-01-05 at 10 55 23

Semua 247 komentar

  • 1

Akan keren jika ini diekspos sebagai ekstensi dalam beberapa cara. Saya khawatir bahwa dalam beberapa kasus, pohon itu dapat sedikit tercemar dengan warna dan terlihat seperti pohon Natal. Atau jika tidak, setidaknya ada opsi untuk mengaktifkan dan menonaktifkannya.

Ya saya setuju. Saya membuat masalah terpisah agar ini diekspos di API ekstensi (lihat #1394).

+1

Akan menyukai itu juga. Tab Git sangat berguna tetapi ini untuk tujuan lain - memiliki warna seperti di Atom akan sangat gratis untuk melihat sekilas apa yang berubah dan di mana (dengan warna menyebar secara otomatis ke direktori teratas). Itu mungkin fitur yang paling saya rindukan dari Atom.

Biasanya, Anda tidak memiliki 10-an atau 100-an file yang dimodifikasi yang tidak dikomit, jadi sepertinya tidak akan terlihat seperti pohon Natal :)

Jadi sepertinya PR untuk ini sudah ditutup. @bpasero @joaomoreno -

Tidak ada pembaruan...

Terima kasih banyak atas minat Anda pada masalah ini! Saat ini ditugaskan ke backlog. Setiap bulan kami memilih item dari backlog untuk merencanakan iterasi saat ini. Silakan lihat https://github.com/Microsoft/vscode/wiki/Issue-Tracking#planning untuk informasi lebih lanjut.

Karena kami adalah tim kecil pengembang, hanya ada begitu banyak permintaan fitur dan masalah yang dapat kami tangani untuk satu pencapaian. Namun demikian, kami selalu menerima permintaan tarik dan dengan senang hati menerimanya jika memenuhi standar kualitas kami.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Tolong berhenti menulis +1 . Ini mengirim email ke semua orang dalam masalah ini. Gunakan reaksi emoji pada komentar pertama.

+1

Hai, apakah Anda punya berita tentang permintaan fitur ini? Saya mulai menggunakan vscode hari ini dan saya sudah menyukainya tetapi saya sangat merindukan warna yang menunjukkan perubahan
Selamat atas karyamu

+1

Saat menerapkan ini, harap pertimbangkan 206

Saya menambahkan beberapa tangkapan layar untuk membantu:

Standar atom:

screen shot 2016-12-15 at 12 29 11

Standar VSCode:

screen shot 2017-01-05 at 10 55 23

+1

+1

Ini akan sangat berguna.

sudah ada kemampuan untuk memodifikasi cara file dan ikon terdaftar di pohon file.
Ekstensi ini melakukannya
https://github.com/robertohuertasm/vscode-icons.

Namun itu tidak mewarnai nama file

+1

+1

apakah ada perubahan? Fitur ini menghentikan saya berpindah dari Atom. :(

Saya baru saja pindah dari Atom karena kinerjanya terasa jauh lebih baik di VSC. Namun, ini adalah fitur mewah yang saya lewatkan di VSC.

+1

Saya pikir akan lebih baik untuk memiliki ini sebagai pengaturan bawaan (misalnya git.colorExplorer ) alih-alih ekstensi.

@arkon apakah ada ekstensi seperti itu? Saya tidak dapat menemukannya.

Kemungkinan besar file explorer tidak memiliki API untuk memodifikasinya sesuai
untuk mengubah git. Perpanjangan akan baik-baik saja bagi saya.

Pada Jumat, 3 Februari 2017, 07:52 Rahul [email protected] menulis:

@arkon https://github.com/arkon apakah ada ekstensi seperti itu? aku tidak bisa
menemukan apapun.


Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-277177373 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEQJ1eoLm7Sp59a2hE0tIFQnb0Q5cJnSks5rYs6tgaJpZM4GlYyH
.

@rahulnever2far Tidak, itu hanya saran karena sebelumnya disarankan bahwa itu bisa diekspos sebagai API ekstensi (yang juga oke, saya kira).

Baru-baru ini memutuskan untuk pindah ke VSCode dan saya sangat merindukan fitur ini

Silakan tambahkan. Menambahkan gesekan pada produktivitas saat mencoba melompat dari Atom.

@KozhokarAlex @bhudgens dan lainnya: klik ikon jempol ke atas di pos pertama untuk menunjukkan kepada pengembang bahwa Anda meminta fitur ini. Mereka mengurutkan masalah berdasarkan jempol untuk menentukan permintaan fitur mana yang paling populer.

Seperti yang Anda lihat dari penyortiran masalah semacam ini, masalah ini adalah fitur yang paling banyak diminta ke-3 saat ini.

Jempolan. Baru-baru ini datang dari Atom..berharap untuk segera melihatnya di VSCode!

Ah terima kasih @joaomoreno!

Harap tambahkan juga status pewarnaan/qit yang sama ke QuickOpen, bukan hanya FileExplorer.
Dengan cara ini membuka file dapat difilter secara visual berdasarkan file yang sudah diubah.

apa yang terjadi dengan ini? mengapa pengelola tidak menggabungkan @joaomoreno PR ? apakah ada plugin yang bisa kita gunakan sekarang? ini hanya rencana konyol

@SOSANA Tidak yakin apa yang Anda maksud dengan PR, PR mana yang Anda maksud?

2824 membuka pintu untuk memperbaiki yang satu ini, jadi bersabarlah sedikit lagi.

@SOSANA itu masalah, bukan PR

+1 fitur ini akan luar biasa untuk produktivitas

+1

@publiclass1 @hevans90 , ... (masukkan semua orang lain yang berkomentar dengan +1) ..., TOLONG jangan posting komentar tentang seberapa besar Anda menginginkan fitur ini. Untuk itulah GitHub menambahkan reaksi emoji. Cukup acungkan jempol pada komentar aslinya. Dengan begitu saya dapat kembali menggunakan pemberitahuan email untuk tujuan apa mereka (terus perbarui tentang kemajuan masalah ini, dan bukan siapa pun di dunia yang juga menginginkan ini). Maaf semua orang karena juga mengirimi Anda spam. Saya sangat berharap lebih banyak orang akan belajar menghentikan masalah +1 -ing.

+1

Saya menggunakan PhpStorm Tapi lebih suka menggunakan Kode VS untuk semuanya. Saat ini saya menggunakan sebanyak mungkin jendela VS Code. Bisakah Anda akhirnya memiliki sistem pewarnaan ini sebagai opsi karena saya lebih suka / tahu warna PhpStorm. Sebagai referensi:

Hitam - Terbaru - File tidak berubah.
Abu-abu - Dihapus - File dijadwalkan untuk dihapus dari repositori.
Biru - Dimodifikasi - File telah berubah sejak sinkronisasi terakhir.
Hijau - Ditambahkan - File dijadwalkan untuk ditambahkan ke repositori.
Coklat - Tidak Diketahui - File ada secara lokal, tetapi tidak ada dalam repositori, dan tidak dijadwalkan untuk ditambahkan.

dll melalui https://www.jetbrains.com/help/phpstorm/2016.3/file-status-highlights.html . Kalian rock, Terima kasih.

dan

  • file yang digabungkan dengan konflik ditampilkan merah,

Sangat mudah untuk membedakan konflik dari yang lain

+1 Harus beralih bolak-balik antara tampilan Git <> Explorer sangat tidak produktif.

Idealnya adalah mungkin juga untuk melihat changeset sebagai grup di atas tempat kami memiliki file Buka, serta pohon perubahan bersarang yang divisualisasikan berdasarkan warna (seperti yang ditunjukkan oleh @abdonrd di atas.)

Ayo satu orang, berhenti saja dengan +1.

Tolong acungkan jempol di postingan pertama.

Saya punya kasus penggunaan dan argumen yang menarik untuk membuat API generik yang memungkinkan plugin mewarnai file dan folder individual:

Penuaan file/folder mirip dengan Trello aging powerup - Saya ingin file dan folder yang sudah lama tidak disentuh (dinilai dari riwayat git) memudar, sehingga 'set kerja' akan lebih berbeda dan lebih mudah ditemukan.

Mengapa: Saya memiliki repo besar proyek kecil (pikirkan banyak skrip untuk laporan analitik) di mana 90+% pekerjaan tidak akan disentuh lagi (tetapi saya tidak dapat memindahkan barang lama ke subfolder karena akan merusak banyak tautan menunjuk ke repo).

Jika ada titik akhir API untuk mewarnai item pohon, saya bisa menulis plugin yang membaca git log dan mewarnai setiap file/folder sesuai dengan beberapa aturan.

Jadi bagaimana, apakah masih ada API yang memungkinkan untuk membuat ekstensi ini, atau ini akan diimplementasikan sebagai fitur terintegrasi?

Ada pembaruan tentang ini?

+1

+1

+1

Bisakah kalian berhenti memberi +1 dan mengirim spam ke kotak masuk email kami ???

Tidak ada gunanya sama sekali.

+1 tanpa spam xD

protip: menyaring pesan dari github di mana tubuhnya sama/cocok/lolwuts "+1"

Anda tidak bisa menghentikan orang-orang ini.

@jmbelloteau seperti yang dikatakan @fredrikaverpil sebelumnya di komentar, masalah VSCode diurutkan berdasarkan jumlah jempol ke komentar asli. Jadi berkomentar "+1" alih-alih menambahkan reaksi ke komentar pertama memang spam, karena itu bukan cara yang benar untuk memberikan umpan balik dan hanya mengirim email yang tidak berguna ke semua orang. Dan bertentangan dengan menambahkan reaksi, itu bahkan tidak akan diperhitungkan.

+1

Saya sangat terbiasa dengan ini di Webstorm juga :D. Tapi seperti yang saya lihat ini mungkin akan dikembangkan lebih cepat daripada nanti. Berikut adalah tangkapan layar dari Webstorm untuk inspirasi (mengikuti @abdonrd):

screen shot 2017-04-16 at 19 03 16

Ah, juga file yang tidak terlacak ditampilkan sebagai merah!

+1

Baru saja mencoba kode VS untuk pertama kalinya hari ini (berasal dari Atom) dan salah satu ekstensi pertama yang saya cari adalah penyorotan "git status" di tampilan explorer. Tab "kontrol sumber" sendiri sangat bagus, tetapi memiliki folder/file yang disorot memungkinkan saya untuk dengan cepat menavigasi ke komponen yang sedang saya kerjakan tanpa harus selalu membiarkan pohon direktori saya diperluas (sangat berguna untuk basis kode FE yang cenderung memiliki struktur bersarang lebih dalam).

idealnya, akan lebih bagus jika warnanya bisa dimodifikasi satu per satu.

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

+1

Saya telah mencari beberapa saat untuk aplikasi yang bagus untuk mengingatkan saya untuk minum air.
Kemudian, saya menyadari bahwa saya berlangganan utas ini.
Terus +1 datang guys, mereka tidak berguna lagi

@mmazarolo
Mengapa Anda perlu pengingat untuk minum air? Apakah tidak cukup minum saat Anda haus?

Bagaimanapun, tolong hentikan pemberian +1. Saya yakin para pengembang sudah mengetahui hal ini dan akan memposting pembaruan saat mereka datang.

@pohmelie itu alternatif yang valid, terima kasih!

+1

wtf salah dengan orang +1 ini?

Ide bagus, @davidhu2000! Akan menyenangkan untuk mendukung warna hex seperti git.ignoredFileColor: '#333333' , juga.

Ada daftar bagus tentang jenis dan warna yang digunakan JetBrains di sini: https://www.jetbrains.com/help/idea/2017.1/file-status-highlights.html (Anda dapat memeriksa nama warna untuk mendapatkan hex).

+1 meningkatkan kesadaran tentang seberapa banyak fitur ini diinginkan

Satu-satunya alasan saya tidak menggunakan VS Code. Sayang sekali :(

Adakah yang tahu di mana dalam basis kode orang mungkin mulai mengimplementasikan ini? Saya ingin menusuknya.

@admosity Seseorang sudah mengajukan permintaan tarik tahun lalu yang ditolak: https://github.com/Microsoft/vscode/pull/8462 .

2824 disebutkan sebagai pemblokir di suatu tempat di atas, yang telah digabungkan beberapa waktu lalu. Saya akan melihat perubahan di sana untuk memastikan penerapannya sesuai keinginan Tim VS.

@AndreasGassmann luar biasa! Aku akan melihat melalui.

Satu fitur kunci terakhir mencegah saya beralih ke kode vs

Ketika fitur ini digabungkan, saya akan mengubah ke vscode

Saya berlangganan masalah ini karena saya ingin tahu kapan beberapa kemajuan selesai.
Semua orang menyadari betapa diinginkannya fitur ini dan saat ini adalah masalah kedua yang paling banyak dipilih :).

Jika Anda benar-benar menginginkan fitur ini, cukup upvote komentar pertama, dan hindari menambahkan komentar berulang .

Bagi orang yang merasa bahwa fitur ini perlu untuk beralih ke VS Code. Saya dapat mengatakan itu adalah fitur pertama yang saya lewatkan ketika beralih dari Atom, tetapi IMO ini adalah harga yang kecil untuk membayar IDE yang luar biasa ini.
Terlebih lagi, minggu lalu saya harus melakukan beberapa pekerjaan di Atom dan saya sangat merindukan tampilan git VS Code.

@waderyan Ini adalah dealbreaker yang bergerak dari atom.

Ya silahkan!

+1

+1

+1

Saya membuat peretasan yang sangat buruk yang mengimplementasikan fitur ini dengan memodifikasi workbench.main.js dan menyuntikkan CSS berdasarkan output git status . Jika Anda tidak keberatan menggali file internal Kode VS dan meminta Kode VS Anda mengeksekusi git status setiap 5 detik, lihatlah.

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

Pembaruan 28.6.2017: Memperbaiki bug di mana plugin tidak dapat dimuat saat membuka kembali proyek.
Pembaruan 30.6.2017: Menambahkan penyorotan direktori induk dari file yang dimodifikasi (seperti yang dilakukan Atom).
Pembaruan 1.7.2017: Pencocokan file sekarang dilakukan menggunakan file lengkap atau jalur direktori. Sebelum perubahan ini, direktori disorot jika memiliki nama yang sama dengan direktori lain yang diubah.

Halo,
Saya tidak tahu apakah fitur ini sudah diterapkan atau belum?
Saya tidak menemukan pengaturan atau ekstensi apa pun dan karena ini dibuka hampir dua tahun yang lalu, saya bingung..

@sanjibukai Masalahnya masih terbuka, jadi belum diimplementasikan. Anda dapat menggunakan peretasan yang dibuat @karabaja4 di komentar di atas milik Anda.

Saya baru di sini, tetapi apakah perlu hampir dua tahun untuk menambahkan fitur yang jelas ini?
Secara mengejutkan saya tidak pernah mendengar tentang vscode sampai saat ini, tetapi ketika saya mendengarnya, fitur utama yang dianjurkan adalah bagaimana vscode adalah integrasi git yang baik. Dan memang itu bagus.
Sayang sekali fitur ini masih kurang..
Namun demikian, pertahankan kerja bagus tim vscode 👍

Tidak dapat tetap fokus tanpa fitur ini. Setiap kali saya harus mengingat file mana yang saya edit.

+1

@ karabaja4 mengapa Anda tidak membuat PR dengan peretasan Anda dan mendapatkan umpan balik tentang cara menerapkannya dengan benar?

@saada Saya akan melakukan itu jika saya pikir salah satu kode itu dapat diintegrasikan ke VS Code. Menjalankan proses git status latar belakang jelas bukan cara yang masuk akal untuk mengimplementasikan fitur ini. Setiap kode yang tepat yang mengimplementasikan ini harus ditulis dari awal dan diimplementasikan dengan benar di dalam kerangka sumber Kode VS. Itu banyak pekerjaan dan sayangnya saat ini saya tidak punya cukup waktu. Maaf :(

Menumpuk tidak akan membantu banyak hal ketika metrik yang mereka nyatakan sudah dikatakan sebagai jumlah +1 yang didapat pos asli, bukan dalam balasan. Juga, mengingat ini adalah alat untuk pengembang, saya agak heran betapa banyak hak dan tidak memahami proses sumber terbuka yang terjadi di sini. Permintaan fitur di sini sebagai masalah terbuka. Anda dapat memberi +1 di pos dan melakukannya sendiri (mungkin bekerja dengan pengelola untuk memastikan itu tidak sia-sia) dan meminta penggabungan atau biarkan saja. Jika ini adalah fitur vital bagi Anda, gunakan Atom. Saat saya menulis ini, ada lebih dari 4000 masalah terbuka. Anda harus melatih kesabaran.

(atau gunakan @karabaja4 hack sementara itu - terima kasih atas pekerjaan Anda!)

+1
Melakukan ini karena hanya mendengarkan obrolan devchat dan masalah dengan lebih banyak komentar akan mendapat lebih banyak perhatian

@karabaja4 kerja bagus. Pendekatan lain: bagaimana dengan menjalankan git status di init, dan kemudian memperbarui setiap kali acara onFileSave diaktifkan? apakah ini akan lebih efisien?

mungkin kita bisa mengonfigurasi cara kita me-refresh status git.

+1 ini akan sangat membantu jika ditambahkan

@Kaijun Saya tidak yakin bagaimana saya menerapkannya. Dari mana acara onFileSave berasal?

Jika itu berasal dari Kode pada penyimpanan dokumen (dengan asumsi saya tahu cara melampirkannya), file yang dimodifikasi di luar Kode akan diabaikan, seperti halnya perubahan seperti memindahkan dan menyalin file.

Jika itu berasal dari logika tontonan folder yang diimplementasikan pada pohon solusi, ini harus dilakukan secara rekursif untuk seluruh pohon. Saya tidak yakin apakah itu layak dari segi kinerja.

@ karabaja4 Saya pikir Kode mendeteksi perubahan luar juga. Jadi menghubungkan ke "acara" seperti itu dengan mungkin sistem debounce sehingga beberapa perubahan file dalam interval yang sama tidak memicu terlalu banyak pemeriksaan status git. Ini bisa berhasil!. Mungkin seseorang yang akrab dengan bagian fs dapat bergabung?

Ini benar-benar tidak boleh di backlog. Ada nilai yang sangat nyata dalam menambahkan fitur yang tampaknya kecil ini. Kebahagiaan pengembang berjalan seiring. Mengecewakan melihat masalah ini memiliki ribuan +1 dan diabaikan sejak 2015.

@kamok benar itu! Meskipun Atom lambat, saya memiliki pilihan lain... Saya kembali ke WebStorm, yang tidak terkalahkan dalam hal integrasinya dengan Git plus fitur lain yang harus Anda instal ekstensinya di vscode, dan masih bisa berjalan begitu cepat dan tampak seperti editor ringan daripada IDE, dalam hal kecepatan. Fitur ini saja (status Git di file explorer) masih tidak akan cukup untuk mempertahankan pengguna vscode. Ini akan menjadi hanya setetes dalam ember. Ini adalah fitur yang paling saya rindukan, berasal dari WebStorm.
Saya menyarankan agar tim vscode melihat bagaimana orang-orang di JetBrains melakukannya.
Maaf, tapi saya sudah mencoba ... Saya telah berjuang dengan vscode selama berbulan-bulan sekarang, menunggu pembaruan setelah pembaruan, tetapi saya masih terus menemukan diri saya terus-menerus menutup vscode dan membuka kembali proyek di WebStorm untuk: Status Git di penjelajah pohon, Simpanan, tampilan folder/pohon untuk perubahan lokal, perbandingan cabang, klik kanan > bandingkan dengan clipboard... Dan ini hanya di luar kepala saya. Integrasi Vscode Git masih memiliki jalan panjang jika mereka benar-benar ingin membantu pengembang.

_Dikirim dari Samsung SM-G950F saya menggunakan FastHub _

@MrCroft Saya menyarankan agar Anda menghubungi tim secara langsung jika Anda sangat khawatir tentang metodologi kerja mereka, jika tidak, Anda memberi +1 masalah dengan jempol dan beralih editor jika itu sangat mengganggu Anda.

@cucumbur saya sudah melakukannya (beralih dari vscode). Saya hanya menyatakan kesedihan saya, karena saya sangat menyukai bagaimana rasanya vscode. Saya akan senang jika memiliki integrasi Git yang baik sehingga saya dapat terus menggunakannya. Saya yakin banyak orang merasakan hal yang sama.
Aku akan tetap mengawasinya. Mungkin, siapa tahu, dalam "masa depan yang tidak terlalu lama" itu akan selesai... Selain vscode, saya sebenarnya adalah penggemar berat Microsoft... Perangkat lunak dan perangkat keras, mereka membuat barang berkualitas sangat tinggi 9 dari 10 kali . Saya hanya berharap vscode akan menjadi salah satu dari 9.

_Dikirim dari Samsung SM-G950F saya menggunakan FastHub _

@kamok Setiap masalah baru masuk ke backlog dan tetap di sana sampai ditangani. Saya tidak berpikir fitur ini diabaikan sama sekali. itu hanya membutuhkan lebih banyak perubahan daripada yang Anda sadari. Sejauh yang saya tahu mereka ingin menjadikan ini bagian dari ekstensi api, dan saat ini file tree tidak memiliki banyak fitur untuk mewujudkannya.

Jika Anda mengurutkan masalah berdasarkan jempol, Anda akan melihat bahwa masalah ini adalah yang paling populer kedua, yang pertama sedang dikerjakan dan hampir selesai. Saya cukup yakin mereka akan mulai mengerjakan ini segera setelah yang lain selesai.

Pembaruan sesekali di utas ini akan sangat bagus.

Beralih dari atom tetapi pada proyek besar tidak memiliki file yang diperbarui yang disorot membuatnya sulit untuk dikerjakan.
Beralih kembali ke Atom hingga fitur ini tersedia

Mungkin perlu disebutkan bahwa solusi alternatif/sementara yang akan bekerja untuk saya ... adalah memiliki struktur pohon yang diduplikasi dalam tampilan "Buka Editor". Biasanya tampilan menunjukkan kepada saya file "diperbarui" tetapi itu hanya kumpulan nama file sehingga lebih sulit untuk dikerjakan, berbeda dengan jika jelas di mana dalam proyek file-file ini ditemukan.

Ada pembaruan tentang ini?

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

Saya masokis komentar saya sendiri.

Saya terus mencoba VSCode tetapi karena fitur ini kurang, itu mencegah saya untuk beralih. Tidak menyadari betapa saya mengandalkan fitur ini di Atom sampai saya mencoba untuk beralih.

Tunggu saja ini untuk beralih ke kode VS dari atom, semoga segera diimplementasikan.

+1

dua tahun berlalu

dan anehnya komentar Anda tidak mengubah itu. Kami yang peduli dengan pengembangan dan kontribusi potensial berlangganan utas masalah Anda, komentar Anda tidak membantu apa-apa dan mengirim email yang tidak berguna ke 99 orang

Hei Anda tidak mendapatkan hasil apapun kecuali Anda mencoba, kan?

Saya sangat merindukannya pada awalnya, dan meskipun akan sangat nyaman untuk memilikinya, 'diff explorer' (ikon ketiga di menu vertikal) sangat kuat dan sangat berguna

+1
Akan luar biasa jika ini diterapkan wooow...!

Saya menulis tugas tegukan yang seharusnya menyederhanakan instalasi peretasan (Kode VS 1.15 saja).

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

PS Belum diuji di semua platform, akan sangat menghargai jika seseorang akan mencobanya di OSX.

@ karabaja4 Sepertinya 'peretasan' Anda tidak terlalu rumit untuk diterapkan ke dalam vscode itu sendiri. Karena sepertinya pengembang vscode tidak memperbaiki masalah ini dalam waktu dekat, mungkin Anda dapat membuat permintaan tarik?

@karabaja4 Terima kasih untuk ini! Bekerja untuk saya di macOS Sierra, VSCode 1.15.1.

@karabaja4 Terima kasih! Bekerja di sini di Fedora 26, VSCode 1.15.0. Itu saja membuat peralihan dari Atom jadi jauh lebih nyaman.

@karabaja4 +1 Terima kasih!! Bekerja untuk saya di Ubuntu 14.04 64, VSCode 1.15.1 (instalasi manual)

+1

@karabaja4 +1 Ini luar biasa.

+1

@matti plus satu

_Dikirim dari HTC MSM8996 saya untuk arm64 menggunakan FastHub _

@ibrokemypie minus dua

Dikirim dari HTC MKB826262 saya untuk arm32 menggunakan Lolbug

Ada berita tentang fitur ini?

+1

+1

+1

@karabaja4 TERIMA KASIH man =D <3

+1

Wow, ini seharusnya sudah diterapkan dua tahun lalu

@eosrei +1

+1

+1
Mari kita hadapi kenyataan; Saya suka VSCode, tapi Git tab benar-benar menyebalkan

@karabaja4 Hai, 1,16 baru saja keluar, maukah Anda

EDIT: Bekerja dengan 1.16, hanya saja tidak saat menggunakan ruang kerja multi root.

@karabaja4 👍

@karabaja4 baru saja membuat hari saya menyenangkan. Terima kasih sobat!

+1

+1

Komentar +1 harus menjadi larangan otomatis pada Masalah GitHub...

Akan lebih baik jika GitHub hanya mem-parsing +1 posting dan secara otomatis menggantinya dengan reaksi emoji jempol ke posting asli.

@karabaja4 peretasan Anda berjalan di OSX 10.12.6 - luar biasa! Terima kasih.

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

Satu-satunya hal adalah saya sekarang mendapatkan pesan Peringatan saat boot. Untungnya, itu hanya peringatan.

VSCode Versi 1.16.0

+1

Apakah ada alasan mengapa ini belum diterapkan atau adakah timeline kapan fitur ini akan ditambahkan?

Kemarin, saya kembali ke Atom selama satu jam untuk menggunakan pembaruan ide terbaru mereka dan saya pikir hidup saya sangat mudah dengan file berwarna dalam tampilan pohon file.

Sunting: Baru saja menemukan solusi. Menambahkan baris ke salah satu file kode vs (usaha <1 menit) berfungsi seperti pesona! https://github.com/karabaja4/vscode-explorer-git-status

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

Pernahkah Anda melihat bahwa Anda dapat menggunakan reaksi emoji alih-alih memposting +1 ?

Setiap kali kami memposting komentar di github, semua pelanggan topik menerima pemberitahuan dan beberapa pengguna juga menerima email. Agak frustasi membaca email yang ditulis: +1 dan Anda dapat melihat di komentar itu, ada banyak :-1:.

Komunitas menghargai jika kita semua mulai menggunakan reaksi sebagai gantinya:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Saya mohon maaf atas pelanggaran apa pun dengan info ini dan untuk orang lain yang mendapatkan pemberitahuan ini.

Saya telah membaca di utas lain bahwa Microsoft menilai prioritas fitur dengan jumlah komentar +1. Saya minta maaf jika saya memiliki kesalahan ini dan dengan cara apa pun tidak ada peringkat fitur. Saya menghapus komentar saya. Either way, ada apa dengan sikap agresif bro? Anda bisa menunjukkan hal yang sama dengan nada yang lebih baik @leocaseiro

Bersulang.

Hai @aecorredor , saya minta maaf jika terdengar kasar.
Saya bukan penutur asli bahasa Inggris dan mungkin salah satu ekspresi terjemahan saya terdengar buruk. Tolong, bantu saya untuk meningkatkan deskripsi untuk komentar itu. Haruskah saya mengganti kata menjengkelkan? tidak berguna? Terima kasih.

PS: Saya senang Anda mengedit dunia yang saya baca di email saya, karena saya mungkin terdengar kasar, tetapi saya tidak pernah bermaksud menyinggung siapa pun.


Pembaruan: Saya telah mengganti komentar saya sebelumnya, beri tahu saya jika terdengar lebih baik. Terima kasih

Hai @leocaseiro ,

Maaf untuk menulis kata yang buruk di tempat pertama. Aku benar-benar menyadari
bahwa kendala bahasa mungkin yang menyebabkan kebingungan. Tetapi
ya, saya akan mengganti dua kata itu dengan sesuatu yang lebih seperti:
"Tolong, kami semua berusaha meningkatkan pengalaman github secara keseluruhan untuk
buka masalah/permintaan fitur, dan alangkah baiknya jika orang mulai menggunakan
reaksi emoji alih-alih komentar seperti "+1", yang baru saja membuat
overhead yang tidak perlu di utas, dan memicu email yang sebenarnya tidak
berkontribusi dengan cara apa pun yang berarti. Silakan merujuk ke tautan ini untuk melihat caranya
reaksi emoji berfungsi: { Tautan di sini }

Ceria, dan tidak ada perasaan sulit.

Terbaik.

Pada Senin, 18 Sep 2017 pukul 23:44, Leo Caseiro [email protected]
menulis:

Hai @aecorredor https://github.com/aecorredor , saya minta maaf jika terdengar
kasar.
Saya bukan penutur asli bahasa Inggris dan mungkin salah satu terjemahan saya
ekspresi terdengar buruk. Tolong, bantu saya untuk meningkatkan deskripsi untuk
komentar itu. Haruskah saya mengganti kata menjengkelkan? tidak berguna? Terima kasih.

PS: Saya senang Anda mengedit dunia yang saya baca di email saya, karena saya mungkin
terdengar kasar, tetapi saya tidak pernah bermaksud menyinggung siapa pun.


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-330420547 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AIsVa9fgWXPMFBgkZdHjQHKhUEDJb8Bmks5sjziWgaJpZM4GlYyH
.

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

Gunakan reaksi sebagai pengganti komentar "+1".

+1

Saya sangat berharap jumlah +1 akan berkurang setelah komentar sebelumnya, tetapi tiba-tiba +1 lain muncul 😁 .

Sayang sekali, karena programmer sering menyalahkan pengguna karena tidak membaca pesan kesalahan, tetapi tidak dapat membaca beberapa komentar atau instruksi.

Mungkin ada baiknya meletakkan sesuatu di README.md untuk meminta pengguna menggunakan reaksi alih-alih berkomentar +1? Mungkin di CONTRIBUTING.md agak tersembunyi.

Saya tidak tahu, saya pikir saya akan berhenti berlangganan dan menunggu catatan rilis ketika sudah siap.

Saya telah membuat Gist yang menangani ini. Perbaikan oleh @ karabaja4 tidak menghilangkan file/folder yang diabaikan dengan benar (lihat masalahnya). Ada PR oleh @dseipp yang tidak pernah digabung. Masih ada yang salah dengan PR-nya (saya pikir dukungan bertahap yang hilang?), jadi saya memperbaikinya.

Jadi jika Anda ingin ini bekerja lebih baik, lihat Intisari saya: https://Gist.github.com/WadeShuler/163773371ad126779076344c34278f3

@ikatyang : maaf, apakah itu berarti fitur ini diperkenalkan pada bulan oktober (2017)..?

@nkkollaw tautannya berasal dari komentar ini: https://github.com/Microsoft/vscode/issues/34160#issuecomment -331066864

Komentar itu hanya meminta untuk membahas hal-hal yang terkait dengan masalah ini di sini, dan bukan di "Rencana Iterasi" (dan meminta untuk membahasnya dalam bahasa Inggris).

Ah, mengerti @tiangolo , terima kasih.

Saya akan mencoba bertahan dengan Atom sampai ada API untuk mengimplementasikan fungsi ini (maaf, saya tidak cukup baik untuk membantu sama sekali dalam hal ini).

saya sedang mengerjakan pembaruan di dalam proyek itu sendiri.
Untuk saat ini, saya membuat bukti konsep yang berfungsi tetapi saya tidak lulus tslint, karena saya masih perlu memahami lapisan untuk meletakkan semuanya di tempat yang tepat.
Saya akan memberikan beberapa pembaruan di sini, dan jika seseorang ingin membantu saya, saya akan memasukkan tautan ke permintaan tarik saya nanti, jadi Anda dipersilakan untuk membantu.

Direncanakan pada Oktober 2017 iterasi!! 👍

Kami memiliki versi pertama ini. Semua orang yakinlah bahwa ini akan datang pada bulan Oktober.

oct-09-2017 18-09-19

Sedikit informasi lebih lanjut:

  • Warna akan ditentukan dalam tema yang berarti dapat disesuaikan dengan selera Anda
  • Akan ada pengaturan untuk mengaktifkan/menonaktifkan ini
  • Ini tidak eksklusif untuk kontrol versi. Kami juga mencari kesalahan/peringatan yang disorot di file explorer (lihat #782) dan kami berpikir untuk mengekspos ini ke pembuat ekstensi.

Pertanyaan-pertanyaan terbuka:

  • Apakah menggunakan satu warna saja sudah cukup? Haruskah ada juga petunjuk tekstual dan/atau ikon?
  • Status anak mana yang harus diambil orang tua? Haruskah ini berjalan dengan penting? Itu mudah dengan kesalahan dan peringatan tetapi apa yang lebih penting, file yang diubah, tidak terlacak, atau diabaikan?
  • Haruskah kita menunjukkan dekorasi file ini juga di ember "Buka Editor" dan/atau pemilih file dll?

Saya akan terus memperbarui masalah ini saat hal-hal terjadi. Seperti biasa, gunakan emosi alih-alih komentar "+1". Terima kasih dan Selamat Coding!

Secara pribadi, apa yang saya lihat pada gambar di atas sudah cukup. Tampak hebat dan terima kasih!

Tampaknya melewatkan file yang diabaikan oleh .gitignore dalam abu-abu gelap?

Anda tidak mengubah warna (abu-abu) folder induk hanya untuk file yang diabaikan di dalamnya. Anda hanya menghapusnya JIKA folder itu sendiri diabaikan. Silakan lihat komentar saya/perbaiki beberapa komentar. Itu membuat Git membuang status dan mendeteksi apakah itu direktori atau file. Cukup menambahkan kelas ke file/folder di pohon file akan berfungsi... Seperti "git-status-modified" atau "git-status-added". Kemudian tema dapat melakukan keajaibannya.

Alangkah baiknya jika kalian membiarkan kami menarik apa yang sedang kalian kerjakan, sehingga kami dapat memainkannya, dan membuat PR. Sejujurnya, jika kacau, orang mungkin akan berhenti menggunakan Kode jika solusi yang layak tidak dapat dicapai dalam waktu yang wajar. Banyak orang (termasuk saya) telah meninggalkan Atom karena masalah serupa.

Saya juga berpikir jika ada kesalahan, mungkin menggunakan titik sebelum atau sesudah nama file di pohon. Ini tidak akan mengganggu, biarkan tema menatanya, dan tidak akan mengganggu penyorotan warna Git.

Ya ini HARUS dibuka untuk pengembang ekstensi! Seharusnya sudah dilakukan. Mengapa kita tidak ingin memiliki kendali atas pohon file untuk membuat ekstensi keren atau memperbaiki hal-hal yang tidak kalian lakukan?

Tampaknya melewatkan file yang diabaikan oleh .gitignore dalam warna abu-abu gelap?

Tentu, ini sedang dalam proses dan hal-hal terjadi satu per satu. File yang diabaikan akan datang, juga pada bulan Oktober.

Alangkah baiknya jika kalian membiarkan kami menarik apa yang sedang kalian kerjakan, sehingga kami dapat memainkannya, dan membuat PR.

Tentu, semuanya ada di joh/feco -cabang. Ada layanan dekorasi baru yang menggunakan penyedia untuk data aktual. Di sisi konsumsi adalah label file yang kami gunakan untuk merender nama file

Anda tidak mengubah warna (abu-abu) folder induk hanya untuk file yang diabaikan di dalamnya. Anda hanya menghapusnya JIKA folder itu sendiri diabaikan. Silakan lihat komentar saya/perbaiki beberapa komentar.

Saya pikir "file yang diabaikan dan anak-anaknya (jika ada) berwarna abu-abu" cukup jelas.

@nkkollaw Apa yang kamu bicarakan?!

Dalam @jrieken berkata:

“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?“

Dia menunjukkan file yang diabaikan yang mungkin memengaruhi status folder induk, yang seharusnya tidak!

Pesan agresif pasif Anda hanya menyumbat utas ini dengan pesan yang tidak membantu...

@WadeShuler : Saya tidak tahu apa yang _you_ bicarakan.

Saya baru saja menunjukkan bahwa file yang diabaikan dan anak-anaknya harus berwarna abu-abu, dan itu cukup jelas bahwa definisi ini tidak meminta orang tua dari file yang diabaikan untuk diklik.

Adapun:

Pesan agresif pasif Anda hanya menyumbat utas ini dengan pesan yang tidak membantu...

Saya tidak tahu bagaimana pesan saya pasif-agresif — saya kira Anda tidak tahu apa artinya — tetapi Andalah yang menyumbat utas ini, karena Anda satu-satunya yang berkomentar setelah pesan saya.

Aneh.

wah.. ide bagus! saya suka itu!

Saya ingin memiliki xcode seperti petunjuk tekstual karakter tunggal di kolom kanan. Membuat file mudah difilter/diikuti secara visual.

@nkkollaw saya berkata:

Anda tidak mengubah warna (abu-abu) folder induk hanya untuk file yang diabaikan di dalamnya. Anda hanya menghapusnya JIKA folder itu sendiri diabaikan.

Jelas, saya berbicara tentang folder induk, bukan anak-anak. Di sini, saya menggambar Anda:

vscode-git-status-tree-explain

Ini adalah .gitignore di direktori induk, web untuk referensi:

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

Pesan saya adalah tanggapan atas balasan @jrieken dari WIP, di sini , di mana dia berkata:

Status anak mana yang harus diambil orang tua? Haruskah ini berjalan dengan penting? Itu mudah dengan kesalahan dan peringatan tetapi apa yang lebih penting, file yang diubah, tidak terlacak, atau diabaikan?

Menunjukkan bahwa induk dari file/folder "diabaikan" dapat memiliki status, yang tidak. Demikian balasan saya. Anda membingungkan apa yang Anda lihat secara visual, vs apa yang sebenarnya digunakan Git untuk daftar abaikannya

➜  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 berarti itu didefinisikan dalam .gitignore dengan aturan khusus, maka mengapa tidak hanya backend/web/assets/ dan secara khusus adalah direktori aset bernama acak. Anda tidak menentukan setiap file yang diabaikan, ketika berhadapan dengan direktori yang isinya diabaikan. Seperti direktori vendor atau node_modules . Mereka hanya memiliki satu entri dalam entri yang diabaikan git status .

Di pohon file, Anda perlu menambahkan kelas git-status-ignored ke SEMUA elemen (file dan folder) yang dimulai dengan backend/web/assets/6f57f06b/ .

CSS untuk mencocokkan folder file-tree backend/web/assets/6f57f06b/ seperti ini (saat ini membutuhkan 2 aturan!):

#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;
}

DAN

#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;
}

Perhatikan: Dalam aturan pertama, kami mencocokkan judul dengan tanda = saja, jadi persis! Dalam aturan ke-2, kami mencocokkan semua judul dengan ^= , jadi awal string, mencocokkan semua yang lebih dalam dari itu juga (semua anak).

Untuk mencocokkan sebuah direktori dibutuhkan 2 aturan CSS. Jadi saya pikir saat melakukan ini, kita harus melanjutkan dan membuat title pada elemen HTML untuk direktori, untuk menyertakan garis miring. Anda dapat melihat apa yang saya bicarakan di tangkapan layar ini:

vsc-dir-trailing-slash

Ya, komentar Anda pasif agresif, karena Anda bersikap kasar/snark/jelek tanpa benar-benar mengucapkan kata-kata itu. Ditambah Anda salah. Tidak ada yang mengatakan apa-apa tentang anak-anak, dan itu bahkan bukan yang kami bicarakan.


@jrieken
Cara pengaturan Atom saya bekerja: "diedit" lebih diutamakan daripada "ditambahkan". Menghapus file tidak menunjukkan status. Tidak ada status untuk "dipentaskan". Saya pikir orang lain harus memeriksa pengaturan Atom mereka dan melihat apakah ini juga berlaku untuk mereka, dan itu bukan hanya pengaturan saya. Akan lebih baik untuk menambahkan kode untuk setiap situasi, dan biarkan pengguna mengeditnya agar berfungsi sesuai keinginan mereka.

Mungkin menambahkan beberapa kelas, sehingga direktori induk sepanjang pohon, akan memiliki "git-status-added" dan "git status-modified". Mungkin bahkan melemparkan "git-status-deleted" jika ada sesuatu yang telah dihapus di bawahnya.

Kemudian gunakan saja css untuk mencocokkannya. Jika Anda menginginkan warna yang berbeda untuk .git-status-added.git-status-modified , Anda dapat membuat font oranye dengan garis bawah hijau (oranye untuk diubah, hijau untuk ditambahkan). Jika hanya memiliki kelas .git-status-added , maka buat font menjadi hijau.

Tidak masalah setelah Anda menambahkan kelas ke dalamnya, semua orang dapat menyiapkan beberapa CSS sesuka mereka. Anda ingin standar "cukup bagus" keluar dari kotak.

Saya akan menarik cabang itu ketika saya punya waktu, dan memeriksanya.


Bagaimana cara menangani kesalahan serat DAN status git?

Atom menempatkan garis merah berlekuk-lekuk di bawah nama file, seperti yang Anda lihat di sini:

image

Saya pikir kita harus menambahkan kelas seperti lint-error ke elemen yang sama dengan status git, yang dapat kita (dan tema) timpa melalui stylesheet kita sendiri.

Jadi div untuk elemen yang sama di pohon file seperti yang saya gunakan sebagai contoh di atas (backend/web/assets/6f57f06b):

<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>

Akan terlihat seperti ini, ketika kita menerapkan status git dari git-status-edited dan 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>

Kemudian kita bisa mencocokkan melalui 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;
}

Apakah kalian punya Slack? Ada banyak file yang diedit di komit. Saya mencari persis di mana Anda menerapkan warna status git ke file-tree. Apakah di /extensions/git/src/repository.ts ?

Terima kasih semuanya dan terima kasih telah mengklarifikasi aturan perubahan, file yang tidak terlacak, dan file yang diabaikan. Orang dalam besok akan mengirimkan versi awal ini.

screen shot 2017-10-24 at 19 51 36 2

Beberapa hal

  • Secara default ada kombinasi warna dan bagde.

    • aktifkan/nonaktifkan ikon dengan: "explorer.decorations.badges": true|false

    • aktifkan/nonaktifkan warna dengan "explorer.decorations.colors": true|false

  • Warna ditampilkan di pohon file, bagian editor terbuka, dan di tampilan SCM
  • Ada tiga warna untuk memulai. Anda dapat menyesuaikannya di workbench.colorCustomizations -pengaturan. Warnanya adalah gitDecoration.modifiedResourceForeground ,
    gitDecoration.deletedResourceForeground ,
    gitDecoration.untrackedResourceForeground ,
    gitDecoration.ignoredResourceForeground , dan
    gitDecoration.conflictingResourceForeground
  • Perhatikan nama pengaturan dll kemungkinan akan berubah, pengaturan baru mungkin ditambahkan, pengaturan lain mungkin dihapus lagi.

FYI - diedit untuk mencerminkan perubahan yang dibuat setelah posting awal

Saya pikir lebih baik tidak menerapkan ikon sisi kanan ke direktori induk. Setidaknya bisa ada pilihan.

Ini tampaknya telah diperbarui dalam versi orang dalam dengan scm.fileDecorations.useIcons dan scm.fileDecorations.useColors diganti dengan scm.fileDecorations.enabled yang memberikan ikon dan warna.

Saya ingin hanya memiliki warna tetapi tidak ikon. YAITU perilaku "lama" dari scm.fileDecorations.useIcons : false dan scm.fileDecorations.useColors : true

Saya telah mencoba bereksperimen dengan explorer.decorations.badges dan explorer.decorations.colors tetapi tampaknya tidak berpengaruh.

EDIT:
Saya menjalankan versi 1.18 insider, Komit f1ee80be081b0d... di windows 10
(Alangkah baiknya jika teks di kotak dialog about bisa di-highlitable sehingga Anda bisa menyalinnya)

Terima kasih telah menyatukan ini @jrieken !

Punya beberapa pemikiran:

  • sepertinya warna yang dipilih masih abu-abu tua bukan warna status
  • setuju dengan opsi untuk memiliki ikon atau tidak (per @FredrikFolkesson )
  • dengan ikon yang ditampilkan, jika warna yang dimodifikasi/diperbarui terang, 'M' atau 'U' harus gelap (atau sebaliknya) sehingga kontras ada dan lebih mudah dibaca.

Menantikan untuk tidak harus memperbarui file main.js dengan setiap build untuk mendapatkan warna!!!

Masalah kecil (saya menggunakan orang dalam terbaru pada 16 Oktober) untuk melaporkan, @jrieken : Warna nama file yang dimodifikasi di pohon proyek tidak ditampilkan jika file ini saat ini dipilih. Harapannya di sini adalah bahwa tidak peduli apakah file tersebut dipilih atau tidak di pohon proyek, warnanya harus sama (menunjukkan file yang dimodifikasi).

Masalah lain yang ingin saya bahas adalah kode warna yang sama tidak hanya untuk pohon proyek, tetapi juga untuk bagian editor terbuka. Saat ini, tidak ada cara untuk melihat di bagian editor terbuka file mana yang dimodifikasi dan mana yang tidak. Kemampuan untuk dengan cepat mengetahui editor mana untuk file yang dimodifikasi SANGAT nyaman, sehingga seseorang dapat melompat di antara file yang dia modifikasi dengan cepat dan tidak perlu mencoba mengingat nama file yang saat ini dimodifikasi.

Ini akan menjadi fitur yang bagus. Baru mengenal VSC dari Atom dan saya sangat merindukannya.

Baru saja pindah dari Atom juga dan juga kehilangan fitur ini. Kapan rilis dengan fitur ini dijadwalkan?

Demikian juga, ini sangat penting karena file gitignored terlalu menonjol dalam daftar dan bercampur dengan semuanya...

Hai, saya rasa kami juga membutuhkan tombol warna untuk mengubah warna latar depan lencana (#36246)

image

Terima kasih semuanya atas umpan balik yang berkelanjutan. Saya telah memperbarui komentar ringkasan awal saya untuk mencerminkan perubahan terbaru. Saya juga memastikan bahwa perubahan pada pengaturan dicerminkan tanpa memuat ulang dan warna status menang atas warna pilihan.

Secara default, kami masih menggunakan warna dan lencana, sebagian besar karena dua alasan: Tidak semua orang langsung tahu apa arti warna dan memiliki lencana (dengan tooltipnya) mungkin membuat ini menjelaskan diri sendiri. Kedua, ada orang, sebenarnya seperti saya, mengalami kesulitan untuk membedakan warna-warna itu dan lencana itu dimaksudkan untuk membuat ini sedikit lebih mudah diakses.

@jrieken Bisakah Anda memberi tahu saya jika kelas CSS diterapkan ke elemen di penjelajah pohon file kiri? Ini akan memberikan perluasan terbaik dan memudahkan pengembang tema, dan kami secara pribadi, untuk menyesuaikan dan mengganti warna.

Misalnya: Ketika perbaikan kode baru Anda menandai file atau folder sebagai ditambahkan, itu harus menambahkan kelas seperti git-status-added . Kemudian kami dapat menargetkan jika melalui stylesheet kami untuk menyesuaikan warna dan tidak terjebak dengan apa yang Anda berikan kepada kami di luar kotak.

@WadeShuler Kustomisasi tema/warna kami tidak bekerja dengan css secara langsung tetapi dengan sesuatu yang kami sebut warna tema . Ini tipuan, memberi nama untuk hal-hal tertentu seperti editorLineNumber.foreground adalah nama warna latar depan untuk nomor baris. Tema menetapkan warna untuk nama-nama itu dan editor mengambil nilai-nilai itu saat merender. Lihat ini untuk latar belakang lainnya: https://code.visualstudio.com/docs/getstarted/theme-color-reference

Dengan orang dalam berikutnya, kemungkinan besok 19, akan ada rendering khusus untuk file yang diabaikan ( git.color.ignored ) dan warna/lencana akan ditampilkan di bagian "Buka Editor". Saya telah memperbarui https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 yang sesuai.

@jrieken Luar biasa! Bagaimana dengan kunci warna untuk latar depan git badges?
https://github.com/Microsoft/vscode/issues/178#issuecomment -336904514

Kerja yang sangat bagus! Sangat menyenangkan melihat fitur ini hadir di vscode.


Dalam implementasi saat ini, file yang dimodifikasi dalam submodul belum ditandai dengan benar sebagai dimodifikasi.

Dalam contoh berikut:

Repositori utama menyertakan submodul di src/components/ . Beberapa file telah dimodifikasi dalam submodule. vscode dengan benar melaporkan src/components/ dimodifikasi tetapi tidak menunjukkan perubahan mana yang dibuat di submodule.

vscode

Atom benar mengidentifikasi file yang dimodifikasi:
atom

Masalah ini mungkin terkait dengan https://github.com/Microsoft/vscode/issues/7829

@jrieken Luar biasa! Bagaimana dengan kunci warna untuk latar depan git badges?

@equinusocio Jangan khawatir, itu akan terjadi tetapi perlu beberapa pemikiran. Ini dijadwalkan untuk Oktober

@jrieken Terima kasih!. Saya melewatkan sesuatu .. ikon folder juga mendapat warna yang dimodifikasi/ditambahkan? Apakah ada kunci baru untuk ditambahkan ke tema ikon untuk mengatur ikon yang berbeda untuk folder ketika git diedit/dimodifikasi?

@jrieken - Masalah di 1.18. Saya ingin mengucapkan terima kasih atas pekerjaan Anda selama ini. Saya baru saja menguji Insider v1.18. Saya membaca sekilas utas di atas, jadi maafkan jika Anda sudah memiliki sesuatu yang sedang dikerjakan untuk 1.19 untuk mengatasi apa yang saya sebutkan di bawah ini.

1) Status "ditambahkan" di pohon file terlihat seperti "diperbarui dan tidak digabungkan" dengan lencana "U". File yang ditambahkan harus memiliki lencana "A".

2) Tidak ada pilihan warna untuk git.color.added

3) Tidak ada pilihan warna untuk git.color.ignored .

4) (Glitch) Ini memperlakukan file "ditambahkan" sebagai "tidak terlacak". Saya memeriksa file "ditambahkan", dan sepertinya di html, sepertinya tidak terlacak. (judul span mengatakan "tidak terlacak" dan kelasnya adalah monaco-decorations-style-32 , ikon "U"). Ini terbukti ketika mengubah warna pada workbench.colorCustomizations untuk git.color.untracked , karena mengontrol file yang seharusnya, "ditambahkan".

5) Mendukung status "R", untuk "diganti nama" atau dipindahkan, tambahkan lencana "R", dan tambahkan pengaturan git.color.renamed .

Terima kasih, saya berharap dapat mencoba 1.19 👍

@danjjl Ada PR tertunda untuk #7829 Dengan itu diterapkan, submodul git mendapatkan pewarnaan.

Ada masalah potensial, jika submodule diubah, saya tidak tahu apakah itu (direktori yang merupakan root dari submodule) akan diperlakukan sebagai warna status direktori di repositori git utama, atau yang berbeda warna berdasarkan file yang terkandung.

Artinya, saya tidak tahu apakah warna direktori submodule akan didasarkan pada 'status git' di direktori induk, atau di submodule. Itu mungkin tidak masalah.

@jrieken Apakah Anda memiliki grup Slack, atau di tempat lain untuk membahas masalah ini? Saya dapat membantu :) Saya dapat menarik, mengembangkan, dan men-debug perubahan saat ini dari cabang master. Saya memperbaiki file "ditambahkan" yang ditampilkan sebagai "U", dan bahkan menambahkan dukungan "bertahap". Karena ini adalah pertama kalinya saya dalam proyek, saya mengatur ulang kembali ke master dan melakukannya lagi. Saya membuat banyak perubahan, dan ingin masuk seperti ahli bedah dan bukan nuklir.

Mengapa ada cek pada raw.x + raw.y diikuti dengan cek pada raw.x lalu raw.y ? Tampaknya menyebabkannya cocok dengan 2 status berbeda.

Mengapa ada 2 konstanta status untuk ADDED / INDEX_ADDED , MODIFIED / INDEX_MODIFIED , dan beberapa lainnya? Saya memahami semua status git yang berbeda, tetapi masuk akal untuk menanganinya untuk pengguna akhir, bukan penamaan status Git. ADDED harus digunakan untuk apa yang Anda miliki sekarang sebagai UNTRACKED untuk kemudian memiliki kode pengaturan git.color.added . Saya pikir beberapa dari konstanta status ini diduplikasi dan harus disederhanakan dan dibersihkan.

Status git dari _M <-- garis bawah = spasi/tidak ada, akan cocok dengan raw.y dan kalian memilikinya sebagai INDEX_MODIFIED . Ini salah, status di mana x = tidak ada dan y = M berarti staged .

Untuk beberapa alasan, terkadang secara acak, tampaknya tidak mencerminkan perubahan. Juga, sepertinya perubahan status git memindai secara rekursif dari atas ke bawah. Jika Anda memiliki proyek besar, Anda dapat melihat status "diabaikan" mengalir melalui folder/file Anda. Untuk mempercepatnya, menavigasi lebih dalam, sepertinya memasukkannya ke direktori itu dan membuatnya abu-abu. -- Apakah proses ini sangat memperlambat sistem/VSCode? Ada yang pernah benchmark? Sebenarnya tidak perlu menelusuri setiap file/folder ketika induknya diabaikan. Anak-anak harus mendapatkan status mereka dari orang tua mereka. -- Jika Anda memiliki 5.000 file ignored tetapi semuanya dalam 2 direktori (yaitu: node_modules, vendor) maka kita tidak boleh memproses 5.000 file, hanya 2 direktori yang mengontrol tampilan turunannya.

Saya akan mengulang perubahan saya hari ini dan mengeluarkan PR.

Terima kasih lagi untuk pekerjaan Anda. Saya hanya mencoba membantu alih-alih mengolok-olok Anda, karena saya sebenarnya bisa melakukannya lol 👍

@WadeShuler saya bisa menjawab beberapa dari itu. Saya berasumsi Anda mencari di Repository.updateModelState() di repository.ts. Jika Anda mencatat cek raw.x + raw.y, semuanya kembali, jadi Anda sebenarnya tidak bisa melakukan raw.x dan raw.y. Alasan raw.x dan raw.y terpisah, dan alasan INDEX_* adalah karena setiap INDEX_* dipentaskan, hanya apa yang dipentaskan yang berubah. Jika Anda mengganti INDEX dengan STAGE, saya pikir itu lebih masuk akal, meskipun logika yang mereka gunakan secara teknis benar. Lihat https://git-scm.com/docs/git-status , khususnya tabel "Arti XY"
(EDIT: wow pemformatannya buruk. Buka saja yang asli. Ini tabel berwarna merah sekitar setengah jalan.)
Itu jelas apa yang mereka gunakan untuk semua ini.

Dan saya pikir Anda salah dalam kasus _M, yang akan cocok dengan MODIFIED, Indeks tidak dimodifikasi (yaitu, tidak dipentaskan). Kecuali tentu saja Anda melihat duplikat kode ini di tempat lain.

@petkahl Terima kasih, saya sudah familiar dengan Git Status Short Format . Saya menggunakannya beberapa minggu yang lalu untuk memperbaiki status vsc git saya untuk menambahkan status Git dasar hingga ini diselesaikan secara resmi.

Dimungkinkan (entah bagaimana) untuk mendapatkan _M (garis bawah = spasi). Saya tidak yakin bagaimana, mengapa, kapan .. Saya mendapatkan ini lebih awal hari ini (dan juga beberapa minggu yang lalu ketika mengerjakan Gist saya):

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

Sekarang beberapa jam kemudian, saya menjalankannya dan mendapatkan "A". Entah apa yang berubah sejak saat itu..

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

Ketika saya sedang melakukan penelitian untuk Inti saya, saya pikir saya menyimpulkan itu mungkin untuk mendapatkan "A_" dan "_M" untuk dipentaskan. Saya juga telah menemukan situs yang merinci statusnya jauh lebih jelas daripada git-status docs, saya tidak dapat menemukannya lagi lol.


Anda juga bisa mendapatkan "AM" untuk file yang dipentaskan dan dimodifikasi. Buat file kosong baru, tambahkan (tahap), edit file & simpan, periksa status:

➜  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/

Jadi haruskah ini memiliki 2 lencana, "[S][M]" ? Saya lebih suka tahu file mana yang telah saya buat. Ini berguna saat memetik ceri. Mungkin berguna untuk tetap melihat apakah Anda telah memodifikasi file bertahap. Setidaknya harus memiliki lencana bertahap.

@WadeShuler saya bisa mendapatkan _M secara konsisten, dengan melakukan dan memodifikasi. Yang berarti tidak berubah (_=spasi) dalam indeks, tetapi dimodifikasi di pohon kerja.
jadi:
Buat file: ??
git tambahkan file A_
git commit (tidak dalam status, tetapi setara dengan ruang ruang)
ubah file: _M
git tambahkan file M_
modifikasi lagi: MM

Saya tidak benar-benar memiliki pendapat tentang lencana ketika memiliki dua. Saya tidak pernah check-in tanpa melihat jendela status, yang memecahnya dengan jelas, seperti halnya status git biasa. Mungkin hanya pengaturan yang memungkinkan Anda memilih mana yang diprioritaskan? Saya bisa melihat argumen untuk keduanya. Atau dua lencana, kurasa. Apakah akan sama untuk pewarnaan?

Saya telah menambahkan dukungan Staged . Anda dapat melihat perubahannya di sini: WadeShuler/ vscode:gitstatus-fix . Saya juga membuat beberapa lencana pada tab Status Git terlihat sedikit lebih baik dengan membuatnya sedikit lebih besar.

Untuk beberapa alasan, itu menghapus penggelapan/pengabaian direktori vendor , tetapi konten di dalamnya masih berwarna abu-abu dan diabaikan. Saya tidak mengerti mengapa modifikasi sederhana saya berhenti membuat direktori vendor berwarna abu-abu? Itulah satu-satunya masalah dengan apa yang baru saja saya lakukan, dan mengapa saya belum mengeluarkan PR ...

git-status-staged-updates

Jika warna/ikon file bertahap akan disertakan, ini pasti opsional. Secara pribadi, saya lebih suka tidak melihat dipentaskan dalam daftar saya sebagai warna yang berbeda dari warna baru/modifikasi asli.

Setelah Anda mulai memasukkan staged, itu bisa menjadi rumit dengan cepat karena ada kemungkinan untuk memasukkan semua kombinasi dan permutasi dari new/new-staged/modified/modified-staged/modified-staged-modified/new-staged-modified, dll. , yang akan menyebabkan matriks besar warna dan kebingungan.

Saya memilih kita tidak terlalu memperumit masalah ini.

Saya setuju @dseipp. Itulah alasan yang tepat mengapa saya tidak menggabungkan dukungan untuk file yang dipentaskan dalam peretasan awal saya ketika saya membuatnya, karena saya melihat tidak ada gunanya file yang dipentaskan untuk diwarnai.

Tujuan penyorotan warna adalah memungkinkan saya menemukan file baru/dimodifikasi secara sekilas di file explorer. Jika saya mementaskan beberapa file, biasanya sebelum komit atau jika saya sudah selesai dengan mereka, jadi saya tidak menggunakannya untuk diwarnai secara normal.

Jika kita menambahkan warna untuk setiap kemungkinan jenis status git, file explorer akan mulai terlihat seperti pohon natal dan akan sangat membingungkan untuk melihat apa yang sebenarnya terjadi.

@jrieken Satu lagi laporan bug, terjadi pada orang dalam terbaru:

  • Versi VSCode: Kode - Insiders 1.18.0-insider (82dcf9835265cd0a45ec135587ae2a82673f1c8f, 20-10-2017T04:24:25.632Z)
  • Versi OS: Windows_NT x64 10.0.15063

Pada dasarnya, VS Code "lupa" dari waktu ke waktu bahwa beberapa file dimodifikasi dan perlu diwarnai. Misalnya, saya memiliki 6 file yang dimodifikasi saat ini. Kode VS (dengan benar) menunjukkan angka "6" pada tombol git. Tapi, di pohon file proyek saya hanya melihat SATU file berwarna kuning, lima file lainnya sepertinya tidak dimodifikasi. Yang cukup menarik, semua 6 file diwarnai dengan benar di bagian editor terbuka.

@dseipp Itu bisa opsional. Namun, Anda tidak akan pernah melihat warna "dipentaskan" sampai Anda mementaskan file... Jadi itu bahkan tidak terlihat 99% dari waktu, dan seharusnya tidak mengganggu siapa pun..

@ karabaja4 Saya tidak setuju bahwa itu tidak ada gunanya. Anda menegaskan, bahwa Anda tidak pernah menggunakan/memperhatikan/membutuhkan pewarnaan bertahap...

Tujuan penyorotan warna adalah memungkinkan saya menemukan file baru/dimodifikasi secara sekilas di file explorer. Jika saya mementaskan beberapa file, biasanya sebelum komit atau jika saya sudah selesai dengan mereka, jadi saya tidak menggunakannya untuk diwarnai secara normal.

Jadi meskipun fitur ini ditambahkan, itu tidak akan mengganggu Anda ...

Mampu melihat file yang dipentaskan membantu cherry memilih apa yang akan Anda komit. Jika kita memiliki 100 file yang diubah, maka perlu mengelompokkannya, kita dapat menjelajahi pohon file dan dengan mudah melihat apa yang dipentaskan, dan menangkap yang kita lewatkan, untuk memastikan mereka berada dalam komit yang sama.

Berapa kali Anda melakukan beberapa file, kemudian menyadari bahwa Anda melewatkan satu? Anda kemudian memiliki 2 opsi, ubah komit terakhir Anda untuk memasukkan file yang terlewat, atau buat komit baru. Saat bekerja dengan tim, akan lebih bersih dan tidak membingungkan jika mereka memiliki komitmen yang sama.

Pada titik bertahap, tidak masalah jika file telah ditambahkan, dimodifikasi, atau apa pun..


Sejujurnya, cara Visual Studio Code menangani Git, sangat tipis dan buggy. Pohon file besar, Anda benar-benar dapat melihat pewarnaan menetes melalui file/folder. Ini secara acak menjatuhkan pewarna ...

Saya pikir seluruh kebutuhan dukungan Git telah ditulis ulang dari awal.

Saya juga ingin menyuarakan dukungan saya untuk memiliki pewarnaan file yang dipentaskan (opsional tidak masalah selama saya dapat mengaktifkannya).

Inilah alur kerja saya: Saya mulai mengerjakan beberapa fitur/perbaikan bug, menjadikannya status "OKish", yang berarti bahwa kode tersebut kurang lebih berfungsi tetapi memerlukan beberapa pemolesan/penyesuaian/pembersihan atau pemfaktoran ulang. Pada saat itu saya mementaskan perubahan saya. Kemudian lakukan pembersihan dan refactoring. Jika refactoring gagal atau menjadi terlalu berantakan, saya hanya kembali ke keadaan bertahap.

Memiliki kemampuan untuk melihat file mana yang sedang saya modifikasi sangat bermanfaat, dan ketika saya melakukan perubahan, saya tidak ingin kehilangan semua info itu dan mendapatkan pohon polos tanpa warna.

@vvs Saya setuju tentang file yang dipentaskan tidak kehilangan warnanya. Warna harus tetap sampai berkomitmen. Saya hanya lebih suka warna bertahap mempertahankan warna baru/modifikasi dan warna bertahap tambahan tetap opsional.

Mungkin Staged dapat mempertahankan warna yang sama tetapi hanya menambahkan semacam highlight atau bold untuk memberikan kontras.

Ini bisa membantu untuk melihat prior art .. tidak ingat melihat indikator bertahap, tapi mungkin waktu telah berubah

Apakah ikon dalam file explorer untuk file yang dimodifikasi/tidak dipentaskan/... benar-benar diperlukan? Saya memiliki beberapa masalah dengan perhatian, sehingga warna dan ikon mengalihkan perhatian saya dengan sangat mudah. Tidak bisakah itu opsional dan dinonaktifkan secara default? Apakah saya satu-satunya yang terganggu oleh mereka?

Dari sudut pandang pengalaman pengguna, terkadang lebih sedikit lebih banyak, dan banyak yang tidak akan repot mencari opsi untuk menonaktifkan hal-hal ini dan akan terus menderita atau bahkan mengganti editor. Saya pikir itu akan menjadi hal yang baik untuk memikirkan ini dan memutuskan apakah ini benar-benar diperlukan untuk UX yang lebih baik (yang saya asumsikan adalah inti dari ikon-ikon ini.)

* Saya tidak punya waktu untuk membaca setiap komentar tentang masalah ini, jadi tolong beri tahu saya jika apa yang saya tanyakan sesuatu yang sudah dibahas dan saya akan meluangkan waktu untuk membaca semuanya sesegera mungkin agar sejalan dengan apa yang dikatakan. Terima kasih.

Saya pikir itu akan menjadi hal yang baik untuk memikirkan ini dan memutuskan apakah ini benar-benar diperlukan untuk UX yang lebih baik (yang saya asumsikan adalah inti dari ikon-ikon ini.)

https://github.com/Microsoft/vscode/issues/178#issuecomment -336960308 itulah sebabnya kami memiliki warna dan lencana secara default. Setuju bahwa itu membuat UI sedikit lebih berantakan, terbuka untuk saran yang dapat diakses/inklusif tetapi juga apik dan bersih.

@jrieken Terima kasih! Bisakah Anda mengarahkan saya ke komit yang memperkenalkan lencana? Saya akan mencoba untuk menemukan sesuatu yang akan bermanfaat untuk kedua masalah (mengalami kesulitan melihat warna atau tidak tahu untuk apa, dan masalah dengan gangguan).

vscode-git

@jrieken Mari kita ambil halaman dari Xcode dan buat lencananya lebih halus.

Lencana berguna untuk memberi petunjuk kepada pemula, tetapi menjadi berantakan setelah warnanya dipelajari.

Untuk pelepasan sepeda tambahan, saya lebih suka lencana berwarna git.color.ignored (_kiri_ di atas) karena mereka memiliki kepentingan visual yang sama. Artinya, memudar tapi tidak menghilang jika aku membutuhkanmu.

Jika kami menerapkan lencana halus, lencana bilah sisi Kontrol Sumber harus diperbarui untuk konsistensi.

Apa pun arah diskusi lencana, bisakah desain lencana setidaknya konsisten dengan yang ada di sidebar Git? Rasanya sedikit terputus-putus untuk memiliki satu desain untuk sidebar Explorer dan yang berbeda untuk sidebar Git.

Saya suka saran satu huruf dari @jayjun. Saya akan mencobanya hari ini.

Jika kami menerapkan lencana halus, lencana bilah sisi Kontrol Sumber harus diperbarui untuk konsistensi.

Itu akan terjadi, itu ada dalam rencana saya untuk Oktober.

Saya telah memperbarui https://github.com/Microsoft/vscode/issues/178#issuecomment -335511695 dengan tangkapan layar dan nama warna terbaru. Juga, dengan orang dalam besok, kami akan menampilkan lencana yang sama di tampilan SCM, tetapi tidak ada label berwarna. Seperti begitu

oct-24-2017 19-55-03

Terlihat lebih baik

Haruskah lencana menjadi U ? Saya pikir komunitas harus mempertimbangkan. U membuat saya pertama kali berpikir updated . Saya tahu itu untracked dalam terminologi Git, tapi saya pikir A lebih pas, terutama bagi mereka yang tidak terbiasa dengan istilah yang mendasarinya, bahwa U tidak terlacak. - Saya pribadi memilih A untuk ditambahkan. Seperti, itu telah ditambahkan ke repositori Anda.

Kemudian dukungan untuk staged (opsional melalui pengaturan) dan itu cukup dekat 👍

@WadeShuler , bagaimana dengan tanda tanya (?) untuk tidak terlacak? Saya tidak suka A karena memiliki konotasi yang berbeda untuk git daripada yang dimaksudkan di sini, setidaknya dalam pikiran saya.

Sunting: Tapi saya setuju bahwa U bisa membingungkan.

Saya pikir saya akan baik-baik saja dengan tanda tanya. Namun, saya tidak berpikir Kode
hanya mendukung Git, bukan? Saya tidak berpikir kita harus melihatnya secara visual di
editor sebagai "Git", tetapi lebih banyak kontrol versi secara umum.

Apapun masalahnya, saya benar-benar tidak suka "U" lol

Pada Selasa, 24 Okt 2017 pukul 14:20 Peter Kahle [email protected]
menulis:

@WadeShuler https://github.com/wadeshuler , bagaimana dengan tanda tanya
(?) untuk tidak terlacak? Saya tidak suka A karena memiliki konotasi yang berbeda untuk
git daripada yang dimaksudkan di sini, setidaknya dalam pikiran saya.


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/178#issuecomment-339084261 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AJHVkJJNzw89umFiPB0BmgQAZYJNXTHzks5svip7gaJpZM4GlYyH
.

Cukup adil, itu harus agnostik. Tetapi "Tidak diketahui oleh sistem kontrol versi" sebagai ? masuk akal bagi saya. Tapi N (untuk Baru) bisa bekerja juga, dan saya tidak bisa memikirkan kelebihan yang satu itu, meskipun saya yakin orang lain akan melakukannya.

Ya, @jrieken , upaya Anda sangat dihargai! Terlihat sangat bagus! Lencana halus adalah nilai tambah.

Saya dengan @WadeShuler dan @petkahl ingin mengubah U ke sesuatu yang lain. 'N' atau '?' kerja. Namun saya condong ke arah N karena itu akan menjadi 'Baru dan' Dimodifikasi.

Senang melihat ini datang bersama-sama!

Apakah workbench.colorCustomizations.git.color.ignored bekerja untuk semua orang?
Saya menggunakan 1.18.0-insider terakhir diperbarui hari ini dan warna yang diabaikan masih belum muncul. Juga, tampaknya "_deleted_" dan "_conflict_" belum berfungsi... mungkin dengan pembaruan besok,
Tapi yang mengganggu saya adalah warna yang diabaikan. Nama file terlihat sama dengan file berversi - tidak dimodifikasi, artinya tidak ada warna khusus yang diterapkan padanya.
Catatan: Repo di tangkapan layar tidak memiliki file yang dilacak sama sekali. Semua file tidak terlacak. Setelah saya menghapus "_shared.module.ts_" dari .gitignore , itu muncul dalam warna coklat (pengaturan warna saya yang tidak terlacak).

image

Haruskah lencananya menjadi U? Saya pikir komunitas harus mempertimbangkan. U membuat saya berpikir untuk diperbarui terlebih dahulu. Saya tahu itu tidak terlacak dalam terminologi Git

Kami telah menggunakan 'U' sebelumnya, ini bukan masalah yang tepat untuk membahas apa yang lebih baik tetapi saya pikir pengguna git mengetahui terminologi dan untuk penyedia SCM lainnya huruf/ikon lain dapat/harus digunakan (dan itulah yang terjadi hari ini).

Fitur ini belum ditambahkan, dan saya telah aktif di utas ini sejak
itu mulai bergerak maju. Saya telah menyebutkan lencana "U" sejak awal.

Utas ini tentang mengembangkan dan menyempurnakan seluruh fitur, karena
Baru. Jika warna font, gaya lencana, dan warna lencana semuanya dapat diterima
untuk dibahas di utas ini, maka begitu juga surat-suratnya.

Jadi di mana lagi, di luar utas ini, kita telah menggunakan "U"?

Jadi di mana lagi, di luar utas ini, kita telah menggunakan "U"?

Periksa stable, bukan insiders, dan viewlet SCM dengan git. Ini menggunakan U untuk u ntracked file.

@WadeShuler @jrieken Tampilan SCM saat ini (1.17.2) menandai _file yang tidak dilacak_ dengan U abu - A hijau . git status menunjukkan _ditambahkan (bertahap) file_ dalam ANSI hijau .

Jadi saya memahami kebingungan dengan U hijau untuk _file yang tidak terlacak_. Saya juga melihat mata saya sakit karena U hijau bercampur dengan A hijau .

Atom mewarnai file baru yang tidak dilacak dan dipentaskan sebagai hijau , dan Xcode menandai file yang ditambahkan sebagai A selama itu adalah file baru. Keduanya tidak pernah mengganggu saya sedikit pun (tetapi U hijau tidak).

Jadi saya akan menggunakan A hijau untuk _dan_ file baru yang tidak terlacak.

Mari kita lanjutkan 'U' vs 'A' vs '?' diskusi di https://github.com/Microsoft/vscode/issues/36912. Terima kasih.

Saya setuju. Saya pikir lebih baik untuk melanjutkan dengan huruf yang digunakan dalam antarmuka hari ini. Saya juga tidak suka 'U', tetapi saya pikir ini agak di luar cakupan permintaan fitur ini. Jika ini berubah, itu harus berubah di seluruh program.

OK ini adalah utas besar dan saya hanya punya waktu untuk membaca sekilas, jadi saya hanya akan mengatakan di sini: Saya harap ada pengaturan untuk menonaktifkan ini. Saya lebih suka semua nama file dengan warna yang sama dan ketika saya perlu melihat statusnya, saya mengetik git status . :-)

Apakah produk ini ditinggalkan? Tampaknya.

Saat ini, list.activeSelectionForeground tampaknya lebih diutamakan daripada gaya status git, sehingga warna status git tidak dapat dilihat pada file yang dipilih. Saya menemukan informasi ini berguna untuk dimiliki, bahkan pada file yang saat ini dipilih. Adakah kemungkinan gaya status git dapat diprioritaskan ketika explorer.decorations.colors benar?
Perilaku ini diamati pada orang dalam 1.18 8dfa696.

Saat ini, list.activeSelectionForeground tampaknya lebih diutamakan daripada gaya status git, sehingga warna status git tidak dapat dilihat pada file yang dipilih.

Memang, sama di sini pada orang dalam terbaru (baru saja diperbarui). Ketika saya mengklik nama file di pohon proyek, warna entri file berubah (katakanlah, dari kuning/dimodifikasi menjadi netral). Saya juga berpikir bahwa ini adalah perilaku yang agak membingungkan. Warna file tidak boleh berubah saat pengguna mengklik file tersebut.

Btw, masalah yang sama dengan daftar file yang terbuka, ketika Anda mengklik file di sana, warna status git diganti dengan warna pilihan netral.

Btw, masalah yang sama dengan daftar file yang terbuka, ketika Anda mengklik file di sana, warna status git diganti dengan warna pilihan netral.

Nah, hal itu dilakukan dengan sengaja karena pemilihan warna foreground seringkali berbenturan dengan warna dekorasi. Menambahkan lebih banyak warna, seperti git.untrackedSelectedForeground dan git.untrackedFocusedForeground tampaknya tidak terlalu menarik bagi kami. Oleh karena itu kami membiarkan pemilihan warna menang ketika item dipilih dan memiliki fokus.

Atom tampaknya tidak memiliki masalah dengan itu ....

atom-selected-color

Tidak perlu pengaturan baru... Tema akan diperbarui untuk mengakomodasi jika warna latar belakang item yang dipilih mengganggu. Mereka yang gagal melakukannya, komunitas akan memutuskan untuk tidak menggunakan tema-tema itu.

Saya belum memeriksanya, tetapi saya harap "lencana" (yaitu: U, M), masih bukan file svg. Mereka seharusnya hanya berupa teks mentah yang dapat ditata/diwarnai.

Sejujurnya, VSCode seharusnya hanya menggunakan stylesheet untuk hal-hal ini alih-alih pengaturan konfigurasi yang kikuk. Ini terlalu memperumit proses yang agak sederhana.

@WadeShuler Ada pilihan dan fokus dan karena saya melihat kursor editor di

dipilih tapi tidak fokus

screen shot 2017-11-01 at 16 16 35

dipilih dan fokus
screen shot 2017-11-01 at 16 16 47

@jrieken Saya telah memeriksa ulang, dan di Atom saya, dipilih vs terfokus menghasilkan hasil yang sama. Itu tidak pernah kehilangan warna font yellow di jendela file explorer kiri. Di tangkapan layar ke-2 Anda, warna red hilang dari test.foo , yang merupakan masalah.

Saya telah mencoba tema Atom gelap dan terang default, serta sekitar 3 tema lainnya. Default saya (seperti yang Anda lihat di SS saya) adalah Seti (baik UI dan tema). Saya tidak dapat membuat Atom menghapus warna yellow dari file explorer, apa pun yang saya lakukan. Atom versi 1.21.2.

Terpilih
selected

Terpilih & Terfokus
selected-focused

Di luar kotak, Kode VS harus mempertahankan warna status git terlepas dari status yang dipilih atau difokuskan.

Jika masalah Anda adalah tema, itu bukan masalah Anda. Itu adalah tanggung jawab pengembang tema untuk memperbarui dan mengakomodasi.


Di samping catatan: Saya belum memeriksa orang dalam terbaru atau melihat kode, tetapi file git ignored harus menggunakan opacity bukan warna font sehingga selalu x lebih gelap dari file biasa, terlepas dari warnanya.

@WadeShuler terima kasih atas umpan balik Anda tentang bagaimana pengelola tema harus menangani bisnis mereka! Beraninya tim VSCode menyediakan API untuk membantu mereka melakukan itu? Pengembang malas itu!

@fernandofleury Tidak ada yang mengatakan apa pun tentang tidak menyediakan API kepada pengelola tema untuk mengelolanya. Postingan saya tidak mengatakan hal semacam itu. Jadi komentar snarky Anda, sama sekali tidak valid dan tidak beralasan.

@jrieken berkata:

Nah, hal itu dilakukan dengan sengaja karena pemilihan warna foreground seringkali berbenturan dengan warna dekorasi.

Saya bilang:

Jika masalah Anda adalah tema, itu bukan masalah Anda. Itu adalah tanggung jawab pengembang tema untuk memperbarui dan mengakomodasi.

Masalahnya adalah konflik antara warna latar depan (sebenarnya, itu adalah warna latar belakang) dari item pohon file/folder (normal, dipilih, fokus), dan pilihan warna font untuk berbagai status git.

Ini _akan_ menjadi tanggung jawab pengembang tema. Mereka harus memilih warna latar depan item di pohon dan warna font untuk berbagai status git sehingga tidak bertentangan.

Misalnya: Pengembang tema memiliki ThemeX dan warna fontnya untuk item di pohon file explorer adalah yellow . Nah, warna font default-nya akan bertentangan dengan warna status default yellow git. Anda tidak akan dapat mengetahui file mana yang dimodifikasi lagi. Jadi ini akan menjadi tanggung jawab pengembang tema! -- Hal yang sama untuk warna latar belakang untuk item yang dipilih/berfokus pada pohon file explorer vs warna font dari status git.

Apakah ini ditunda sekarang?

@IljaDaderko Saya rasa tidak karena itu muncul di Catatan Rilis v1.18 mendatang dari versi Stabil berikutnya. Pertanyaannya mungkin lebih, apakah ini akan ditutup atau masih ada pekerjaan yang harus diselesaikan?

@IljaDaderko VSCode v1.18 sudah keluar dan termasuk perubahan yang dibahas di sini.

Apakah warna file yang diabaikan seharusnya menjadi bagian dari pembaruan v1.18? Dokumen mengatakan gitDecoration.ignoredResourceForeground dapat digunakan untuk mewarnai file yang diabaikan, tetapi sejauh ini saya belum dapat melihat hal itu memengaruhi apa pun. Pewarnaan yang dimodifikasi / tidak terlacak berfungsi dengan baik. Ini di stable 1.18.0, windows.

Sama di sini (tentang warna yang diabaikan). Belum berhasil untuk saya juga, sejak seluruh implementasi Git ini dimulai. Menggunakan Orang Dalam.
Semua yang dilakukan gitDecoration.ignoredResourceForeground adalah mengabaikan file yang diabaikan dari pewarnaan :)

Ini bekerja untuk saya dan terlihat SPEKTAKULER.

Akhirnya disini

@arxpoetica Inilah yang saya dapatkan:
image

Bagaimana itu bisa bekerja untuk beberapa dan tidak untuk orang lain, saya tidak mengerti. Itu hanya satu pengaturan gitDecoration.ignoredResourceForeground
Apakah saya satu-satunya yang tidak berhasil? Benar-benar tidak ada orang lain? :) Oh, dan @Shurelia
Adakah orang lain (kami, pengguna) yang benar-benar menguji pengaturan warna yang diabaikan sebelum mengatakan itu berfungsi?

OS: Windows 10 PRO (1709)
VSCode: 1.19.0-insider (baru saja diperbarui sebelumnya)
Sama di laptop kantor dan desktop rumah saya.

Apakah ada di Insider? Bagaimana saya bisa menggunakannya?

Selamat, semuanya!

@nkkollaw Di kedua orang dalam dan stabil (1.18)

@MrCroft Silakan diskusikan masalah git-abaikan di sini: https://github.com/Microsoft/vscode/issues/37857

Karena kami telah mengirimkan fitur ini dalam versi stabil terbaru kami, inilah saatnya untuk menutup dan mengunci masalah ini. Harap buat masalah baru untuk diskusi topik dan laporan bug. Masalah di sekitar area ini ditandai dengan file-decorations -label.

Semuanya, terima kasih atas umpan balik yang luar biasa dan berkelanjutan yang menjadikan fitur ini seperti sekarang ini!

Untuk meringkas dan mengulangi komentar saya

screen shot 2017-10-24 at 19 51 36 2

Beberapa hal

  • Secara default ada kombinasi warna dan bagde.

    • aktifkan/nonaktifkan ikon dengan: "explorer.decorations.badges": true|false

    • aktifkan/nonaktifkan warna dengan "explorer.decorations.colors": true|false

  • Warna ditampilkan di pohon file, bagian editor terbuka, dan di tampilan SCM
  • Ada tiga warna untuk memulai. Anda dapat menyesuaikannya di workbench.colorCustomizations -pengaturan. Warnanya gitDecoration.modifiedResourceForeground ,
    gitDecoration.deletedResourceForeground ,
    gitDecoration.untrackedResourceForeground ,
    gitDecoration.ignoredResourceForeground , dan
    gitDecoration.conflictingResourceForeground
Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

chrisdias picture chrisdias  ·  3Komentar

VitorLuizC picture VitorLuizC  ·  3Komentar

philipgiuliani picture philipgiuliani  ·  3Komentar

shanalikhan picture shanalikhan  ·  3Komentar

lukehoban picture lukehoban  ·  3Komentar