Trạng thái Git hiển thị các tệp như đã thay đổi mặc dù nội dung giống nhau


192

Tôi đã nhận được kiểm tra git từ người khác và đang cố gắng thực hiện các thay đổi chưa được thực hiện cho kho lưu trữ cục bộ. Tuy nhiên, rất nhiều tệp (nếu không phải mọi) xuất hiện dưới dạng sửa đổi mặc dù nội dung hoàn toàn giống nhau.

Tôi đã đặt core.fileModethành false và cũng được đặt core.autocrlfthành false, nhưng không thành công.

Đáng nói là repo Git mà tôi nhận được là từ một ai đó sử dụng Windows, trong khi tôi sử dụng Linux.

Tôi có thể làm gì để cam kết những thay đổi thực tế ?

EDIT: đầu ra của git config -l:

user.name=Aron Rotteveel
user.email=<removed>
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.ui=true
color.pager=true
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
core.pager=less -FRSX
core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
alias.co=checkout
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=false
remote.origin.url=<removed>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

Cập nhật: thêm một số tệp ví dụ ngẫu nhiên. Các tệp này chỉ là bản rõ, vì vậy dễ bao gồm nhất.

Các tệp gốc được đặt tại đây: https://gist.github.com/c3c5302430935155ef3d . Hexdumps chắc chắn chỉ ra rằng các tập tin là khác nhau, nhưng tôi không biết nguyên nhân gây ra điều này và cách khắc phục nó.

Phiên bản chính:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740d  HTML.SafeObject.
0000010: 0a54 5950 453a 2062 6f6f 6c0d 0a56 4552  .TYPE: bool..VER
0000020: 5349 4f4e 3a20 332e 312e 310d 0a44 4546  SION: 3.1.1..DEF
0000030: 4155 4c54 3a20 6661 6c73 650d 0a2d 2d44  AULT: false..--D
0000040: 4553 4352 4950 5449 4f4e 2d2d 0d0a 3c70  ESCRIPTION--..<p
0000050: 3e0d 0a20 2020 2057 6865 7468 6572 206f  >..    Whether o
0000060: 7220 6e6f 7420 746f 2070 6572 6d69 7420  r not to permit 
0000070: 6f62 6a65 6374 2074 6167 7320 696e 2064  object tags in d
0000080: 6f63 756d 656e 7473 2c20 7769 7468 2061  ocuments, with a
0000090: 206e 756d 6265 7220 6f66 2065 7874 7261   number of extra
00000a0: 0d0a 2020 2020 7365 6375 7269 7479 2066  ..    security f
00000b0: 6561 7475 7265 7320 6164 6465 6420 746f  eatures added to
00000c0: 2070 7265 7665 6e74 2073 6372 6970 7420   prevent script 
00000d0: 6578 6563 7574 696f 6e2e 2054 6869 7320  execution. This 
00000e0: 6973 2073 696d 696c 6172 2074 6f0d 0a20  is similar to.. 
00000f0: 2020 2077 6861 7420 7765 6273 6974 6573     what websites
0000100: 206c 696b 6520 4d79 5370 6163 6520 646f   like MySpace do
0000110: 2074 6f20 6f62 6a65 6374 2074 6167 732e   to object tags.
0000120: 2020 596f 7520 7368 6f75 6c64 2061 6c73    You should als
0000130: 6f20 656e 6162 6c65 0d0a 2020 2020 254f  o enable..    %O
0000140: 7574 7075 742e 466c 6173 6843 6f6d 7061  utput.FlashCompa
0000150: 7420 696e 206f 7264 6572 2074 6f20 6765  t in order to ge
0000160: 6e65 7261 7465 2049 6e74 6572 6e65 7420  nerate Internet 
0000170: 4578 706c 6f72 6572 0d0a 2020 2020 636f  Explorer..    co
0000180: 6d70 6174 6962 696c 6974 7920 636f 6465  mpatibility code
0000190: 2066 6f72 2079 6f75 7220 6f62 6a65 6374   for your object
00001a0: 2074 6167 732e 0d0a 3c2f 703e 0d0a 2d2d   tags...</p>..--
00001b0: 2320 7669 6d3a 2065 7420 7377 3d34 2073  # vim: et sw=4 s
00001c0: 7473 3d34 0d0a                           ts=4..

Phiên bản sao chép:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740a  HTML.SafeObject.
0000010: 5459 5045 3a20 626f 6f6c 0a56 4552 5349  TYPE: bool.VERSI
0000020: 4f4e 3a20 332e 312e 310a 4445 4641 554c  ON: 3.1.1.DEFAUL
0000030: 543a 2066 616c 7365 0a2d 2d44 4553 4352  T: false.--DESCR
0000040: 4950 5449 4f4e 2d2d 0a3c 703e 0a20 2020  IPTION--.<p>.   
0000050: 2057 6865 7468 6572 206f 7220 6e6f 7420   Whether or not 
0000060: 746f 2070 6572 6d69 7420 6f62 6a65 6374  to permit object
0000070: 2074 6167 7320 696e 2064 6f63 756d 656e   tags in documen
0000080: 7473 2c20 7769 7468 2061 206e 756d 6265  ts, with a numbe
0000090: 7220 6f66 2065 7874 7261 0a20 2020 2073  r of extra.    s
00000a0: 6563 7572 6974 7920 6665 6174 7572 6573  ecurity features
00000b0: 2061 6464 6564 2074 6f20 7072 6576 656e   added to preven
00000c0: 7420 7363 7269 7074 2065 7865 6375 7469  t script executi
00000d0: 6f6e 2e20 5468 6973 2069 7320 7369 6d69  on. This is simi
00000e0: 6c61 7220 746f 0a20 2020 2077 6861 7420  lar to.    what 
00000f0: 7765 6273 6974 6573 206c 696b 6520 4d79  websites like My
0000100: 5370 6163 6520 646f 2074 6f20 6f62 6a65  Space do to obje
0000110: 6374 2074 6167 732e 2020 596f 7520 7368  ct tags.  You sh
0000120: 6f75 6c64 2061 6c73 6f20 656e 6162 6c65  ould also enable
0000130: 0a20 2020 2025 4f75 7470 7574 2e46 6c61  .    %Output.Fla
0000140: 7368 436f 6d70 6174 2069 6e20 6f72 6465  shCompat in orde
0000150: 7220 746f 2067 656e 6572 6174 6520 496e  r to generate In
0000160: 7465 726e 6574 2045 7870 6c6f 7265 720a  ternet Explorer.
0000170: 2020 2020 636f 6d70 6174 6962 696c 6974      compatibilit
0000180: 7920 636f 6465 2066 6f72 2079 6f75 7220  y code for your 
0000190: 6f62 6a65 6374 2074 6167 732e 0a3c 2f70  object tags..</p
00001a0: 3e0a 2d2d 2320 7669 6d3a 2065 7420 7377  >.--# vim: et sw
00001b0: 3d34 2073 7473 3d34 0a                   =4 sts=4.

1
Nếu bạn core.filemodekhông đặt, hoặc đặt thành true, đầu ra có khác không?
Đánh dấu Longair

Một thông tin quan trọng khác sẽ giúp ích là đầu ra củagit --version
Mark Longair

2
@AronRotteveel: Thật dễ dàng: tệp đầu tiên có dòng kết thúc CRLF (windows), LF thứ hai (Unix)
sehe

3
git 2.8 (Tháng 3 năm 2016) giới thiệu git ls-files --eol, để nhanh chóng xem eol có liên quan hay không. Xem câu trả lời của tôi dưới đây
VonC

Người trên windows có thể chạy git config --global core.autocrlf true để giải quyết vấn đề này.
Inyoka

Câu trả lời:


62

Cập nhật: theo nhận xét về câu hỏi này, vấn đề đã được giải quyết:

Điều đó thật dễ dàng: tệp đầu tiên có dòng kết thúc CRLF (windows), tệp thứ hai (Unix) thứ hai. Công cụ file(có sẵn trong git \ usr \ bin) sẽ cho bạn thấy rằng ( file a bsẽ trả lời một cái gì đó như a: ASCII text, with CRLF line terminators b: ASCII text)

Câu trả lời gốc dưới đây:


Khác biệt bạn hiển thị không hiển thị một dòng khác nhau. Bạn có thể đăng .git / config (hoặc tốt hơn git config -l).

Bạn có thể có một số khoảng trắng bỏ qua kích hoạt

Bạn nên cố gắng vô hiệu hóa core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

cũng thế

git show HEAD:myfile|md5sum
md5sum myfile

có thể được sử dụng để xác minh rằng các tập tin trên thực tế là khác nhau. Sử dụng khác biệt bên ngoài cũng có thể làm việc

git show HEAD:myfile > /tmp/myfile.HEAD

diff -u myfile /tmp/myfile.HEAD

# or if you prefer an interactive tool like e.g.:
vim -d myfile /tmp/myfile.HEAD

Điều kỳ lạ là md5sums cho cả hai tệp là khác nhau nhưng tôi không thể tìm thấy bất kỳ sự khác biệt nào về khoảng trắng. (Tôi cho rằng đây là trường hợp, nhưng tôi đơn giản không nhìn thấy nó). Bất kỳ trợ giúp sẽ được hoan nghênh.
Aron Rotteveel

Chỉ cần tải lên một ví dụ ở đâu đó (gist.github.com sẽ thích hợp cho việc này). Tôi giả sử nó là với dòng mới trên dòng cuối cùng, mã hóa theo thứ tự byte hoặc mã hóa UTF8 không chính tắc nói chung. Bạn luôn có thể nhìn vào xxdhoặc bdiffthực hiện khác biệt nhị phân
sehe

cảm ơn vì tiền hỗ trợ. xddlà mới đối với tôi. Công cụ tuyệt vời! Tôi đã cập nhật bài viết của mình với một ví dụ.
Aron Rotteveel

1
@AronRotteveel: Điều đó thật dễ dàng: tệp đầu tiên có dòng kết thúc CRLF (windows), LF thứ hai (Unix). Chỉnh sửa Công cụ filesẽ cho bạn thấy rằng ( file a bsẽ trả lời một cái gì đó như a: ASCII text, with CRLF line terminators b: ASCII text)
sehe

những người thực sự không hiển thị như ^ M trong VIM? (Tôi không thấy nó). Rõ ràng, tôi tin bạn, nhưng tôi thực sự quan tâm đến cách bạn thực sự nhận thấy điều này :)
Aron Rotteveel

134

Tôi đã giải quyết vấn đề này bằng cách sử dụng các stpes sau

1) Xóa mọi tệp khỏi chỉ mục của Git.

git rm --cached -r .

2) Viết lại chỉ mục Git để chọn tất cả các kết thúc dòng mới.

git reset --hard

Lưu ý rằng bước 2 có thể loại bỏ các thay đổi cục bộ của bạn. Giải pháp là một phần của các bước được mô tả trên trang web git https://help.github.com/articles/deals-with-line-endings/


Trong trường hợp của tôi, tôi đã tạo một loạt các ghi chú cho một số tệp, sau đó sao chép repo mà không có thư mục .git sang máy tính mới. Khi tôi nhận ra mình đang thiếu gói .git của mình, đã quá muộn để quay lại và lấy nó. Vì vậy, tôi: 1. Đã kiểm tra một bản sao mới của toàn bộ repo 2. Thay thế các tệp vanilla bằng các tệp bằng các thay đổi của tôi 3. Chạy bước một trong bài của OP: git rm --cached -r .4. Điều này đã thay đổi các thay đổi của tôi (và bất kỳ tệp nào khác đã được thay thế ) vì vậy tôi đã bỏ qua chúng. Lúc này repo của tôi đã trở lại bình thường.
cody

2
Xuất sắc. Cảm ơn vì điều đó.
rupi

6
Hãy cẩn thận vì bạn sẽ mất bất kỳ thay đổi nào khác nếu bạn làm như vậy.
Mohy Eldeen

Tôi gặp vấn đề này sau khi sao chép và dán thư mục repo của mình từ Windows sang Ubuntu. Không có thay đổi cục bộ, nhưng vì một số lý do, git nghĩ rằng mọi tệp đơn lẻ đã thay đổi. Giải pháp này đã giải quyết vấn đề này.
Linek

86

Bạn đã thay đổi chế độ của các tập tin? Tôi đã làm điều đó trên máy của mình và máy dev cục bộ có 777 được cung cấp cho tất cả các tệp trong khi repo có 755 hiển thị mọi tệp như đã sửa đổi. Tôi đã làm git diffvà nó cho thấy chế độ cũ và chế độ mới là khác nhau. Nếu đó là vấn đề thì bạn có thể dễ dàng bỏ qua chúng bằng git config core.filemode false
Cheers


2
Sử dụng Windows 10 lxss (tức là Ubuntu Bash) với repo trong hệ thống tập tin Windows với git trong Linux, tôi đã nghĩ rằng đó là sự cố kết thúc dòng. Thậm chí còn không coi đó có thể là cách các chế độ tập tin khác nhau.
Matt L

Điều này làm việc cho tôi khi tôi thay đổi O / S cục bộ của mình từ Ubuntu sang Windows. Chúc mừng
Mark Bucknell

@MattL và itandy Tôi thường phát triển trên Win 10 với Git Bash, nhưng hôm nay tôi đang ở trên Mac và thấy rằng git nghĩ rằng .gitignorecác tệp đã thay đổi khi họ không có. Trên máy Mac này, git config core.filemodetrả lời với true. Tôi đã thay đổi nó false, nhưng điều đó không giúp được gì.
Ryan

43

Tôi đã từng gặp vấn đề tương tự. Sau khi win-> lin copy tôi đã sửa đổi tất cả các tập tin.
tôi đã sử dụng fromdos để sửa lỗi kết thúc dòng
và sau đó

git add -uv 

để thêm thay đổi.
nó đã thêm 3 tập tin (không phải tất cả chúng), mà tôi thực sự đã sửa đổi. và sau đó trạng thái git chỉ hiển thị 3 tệp đã sửa đổi. Sau khi git cam kết mọi thứ đều ổn với trạng thái git


2
Cảm ơn, đây là những gì tôi cần. Tôi đã sử dụng đề xuất của @ sehe về việc so sánh md5sum để xác minh các tệp giống hệt nhau (trong trường hợp của tôi là như vậy). Sau đó, sử dụng cờ -u đã lọc chính xác các tệp không có sự khác biệt thực tế so với các tệp có thay đổi.
STW

Cảm ơn, nó rất hữu ích. Tôi đã có vấn đề này sau khi thực hiện npm itrong thư mục gốc của dự án của tôi. Bằng cách nào đó, nhiều tệp đã nhận được một kết thúc dòng khác nhau, điều này tạo ra vấn đề này.
Máy chủ Khalilov

đây là những gì tôi mong đợi ... những thay đổi đã được thực hiện và phần còn lại đã hoàn tác
Deepak


24

Trong trường hợp của tôi, các tệp đã xuất hiện dưới dạng sửa đổi sau khi thay đổi quyền của tệp .

Để làm cho git bỏ qua thay đổi quyền, hãy làm như sau:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

1
Câu trả lời của bạn đã tiết kiệm cho tôi rất nhiều thời gian. Cảm ơn!
Pavel_K

Sau khi thực hiện việc này, tôi khuyên bạn nên sắp xếp / sắp xếp các thay đổi mong muốn , đặt lại / kiểm tra các tệp đã thay đổi quyền của họ và sau đó bật lại core.filemode. :)
XtraSimplility

Tôi gặp vấn đề này sau khi sao chép các tập tin từ máy tính xách tay này sang máy tính xách tay khác. Cố định của bạn đã lưu nó. Cảm ơn!
Sam

23

Tuy nhiên, rất nhiều tệp (nếu không phải mọi) xuất hiện dưới dạng sửa đổi mặc dù nội dung hoàn toàn giống nhau.

Với git 2.8 (tháng 3 năm 2016), bạn sẽ có thể nhanh chóng kiểm tra xem những thay đổi đó có liên quan đến eol hay không.

Xem cam kết a7630bd (16 tháng 1 năm 2016) bởi Torsten Bögershausen ( tboegi) .
(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 05f1539 , 03 tháng 2 năm 2016)

ls-files: thêm chẩn đoán eol

Khi làm việc trong môi trường đa nền tảng, người dùng có thể muốn kiểm tra xem các tệp văn bản có được lưu trữ chuẩn hóa trong kho không và nếu .gitattributes được đặt phù hợp.

Làm cho nó có thể để Git hiển thị các kết thúc dòng trong chỉ mục và trong cây làm việc và các thuộc tính văn bản / eol hiệu quả.

Cuối dòng (" eolinfo") được hiển thị như thế này:

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

Thuộc tính text / eol hiệu quả là một trong những thuộc tính sau:

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

git ls-files --eol đưa ra một đầu ra như thế này:

i/none   w/none   attr/text=auto      t/t5100/empty
i/-text  w/-text  attr/-text          t/test-binary-2.png
i/lf     w/lf     attr/text eol=lf    t/t5100/rfc2047-info-0007
i/lf     w/crlf   attr/text eol=crlf  doit.bat
i/mixed  w/mixed  attr/               locale/XX.po

để hiển thị quy ước eol nào được sử dụng trong dữ liệu trong chỉ mục (' i') và trong cây làm việc (' w') và thuộc tính nào có hiệu lực cho từng đường dẫn được hiển thị .


Mặc dù điều này cho thấy vấn đề, nhưng nó không khắc phục được.
Greeso

7

Đây là cách tôi khắc phục sự cố trên Linux trong khi tôi nhân bản một dự án được tạo trên Windows:

trên linux để mọi thứ hoạt động chính xác, bạn phải có cài đặt này: core.autocrlf = input

đây là cách thiết lập nó: git config --global core.autocrlf đầu vào

Sau đó nhân bản dự án một lần nữa từ github.


Điều này làm việc cho tôi trong một kịch bản trong đó tôi đang sử dụng Visual Studio trên Windows, nhưng tôi đang thực hiện các cam kết và kiểm tra bổ sung trong WSL trên dòng lệnh. Trên dòng lệnh, mọi tệp hiển thị là đã thay đổi, nhưng trong Visual Studio, chỉ có một vài tệp thay đổi. Tôi đã thêm autoclrf = input trong tệp .gitconfig của mình và nó đã sửa nó ngay lập tức. Cảm ơn bạn!
Dữ liệu lớn Brian

5

Câu hỏi thường gặp về Git có một câu trả lời có thể có liên quan, mặc dù tôi chưa bao giờ gặp phải điều này trước đây:

Tại sao git diff đôi khi liệt kê một tệp không có thay đổi?

git diff và các hoạt động git khác được tối ưu hóa để nó thậm chí không nhìn vào các tệp có trạng thái (kích thước, thời gian sửa đổi, v.v.) trên đĩa và trong chỉ mục của git là khác nhau. Điều này làm cho git diff cực kỳ nhanh cho những thay đổi nhỏ. Nếu tập tin đã được chạm vào bằng cách nào đó, git diff phải xem xét nội dung và so sánh nó là một hoạt động chậm hơn nhiều ngay cả khi thực tế không có thay đổi. git diff liệt kê các tệp như một lời nhắc rằng nó không được sử dụng tối ưu. Chạy trạng thái git sẽ không chỉ hiển thị trạng thái, mà còn cập nhật chỉ mục với trạng thái cho các tệp không thay đổi đĩa thực hiện các hoạt động tiếp theo, không chỉ khác, nhanh hơn nhiều. Một trường hợp điển hình khiến nhiều tệp được liệt kê bởi diff đang chạy các lệnh chỉnh sửa hàng loạt như perl -pi -e '...'.

Điều gì git statusthể hiện cho bạn?


git statuschỉ đơn giản là hiển thị một danh sách lớn các tập tin trong phần sửa đổi.
Aron Rotteveel

@Aron: dựa trên đầu mối mà tôi muốn nói: 85% cho biết chuyển đổi
lineend

4
Ồ Một lời nhắc nhở về việc một số tài liệu git chính thức khó hiểu như thế nào.
Sao Hỏa

2

Sau khi sao chép kho lưu trữ cục bộ của tôi và sao chép vào một thư mục khác (trên Windows bằng cách này), tôi có bốn tệp tiếp tục hiển thị như đã thay đổi và thử mọi đề xuất được liệt kê trong các câu trả lời khác. Cuối cùng, cái đã sửa nó đối với tôi là xóa chi nhánh địa phương và tải lại từ xa. Trong trường hợp của tôi, tôi đoán nó có liên quan đến việc sao chép một kho lưu trữ cục bộ hơn là nhân bản.


2

Vì vậy, tôi đã thử mọi thứ ở đây và muốn đóng góp thêm một giải pháp khắc phục tất cả các vấn đề của mình. Vấn đề của tôi không phải là kết thúc dòng hoặc quyền thực tế hoặc bất cứ điều gì tương tự. Đó là bởi vì tôi đã cài đặt Cygwin và toàn bộ máy chủ đi kèm với nó, điều mà tôi không biết cũng đã cài đặt phiên bản git của riêng nó. Tôi không bao giờ nhận thấy điều này, chỉ là tôi đã gặp vấn đề lạ với người dùng và các tệp được đánh dấu là đã thay đổi (vì thay đổi perm).

Hóa ra tôi đã tìm ra điều này bởi vì tôi nghĩ rằng tôi chỉ nên cập nhật Git lên phiên bản mới nhất, mà tôi đã làm, nhưng đang chạy git --version lại trả về số phiên bản cũ. Sau cuộc săn tìm lý do tại sao, tôi tìm thấy thư mục gốc của cygwin bin trong đường dẫn môi trường của tôi, trong đó có một tệp thực thi git, chạy ở số phiên bản cũ. Đi hình.

Điều này cũng khó tìm vì tôi đã cài đặt TortoiseGit. Các công cụ dòng lệnh của tôi sẽ sử dụng phiên bản cygwin do lỗi đường dẫn và TortoiseGit được cấu hình để sử dụng phiên bản windows, khiến nó trở nên khó hiểu hơn.

Hy vọng điều này sẽ giúp ai đó.


1
Nắm bắt tốt. +1. Đó là lý do tại sao tôi luôn tự đặt PATH của mình, như trong stackoverflow.com/a/44351065/6309
VonC

Tôi thường sẽ để một trình cài đặt thiết lập PATH nhưng sau đó kiểm tra thủ công, điều mà tôi đã làm ở đây. Cài đặt trước của tôi có git 2.4.x (x86) và tôi đã cài đặt git 2.13.x (x64). Bạn có thể tưởng tượng sự nhầm lẫn của tôi khi tôi xóa tham chiếu đường dẫn x86 và vẫn có 2.4 !! Đó là khi tôi thấy thư mục bin của Cygwin và đó dường như là nơi hợp lý tiếp theo để tìm. Vì vậy, cài đặt FWIW hoặc thậm chí kiểm tra trực quan PATH của bạn có thể không giải quyết được điều này nếu thư mục bin Cygwin được liệt kê đầu tiên!
dudewad

1

Mục nghi ngờ duy nhất trong cấu hình của bạn trông giống như tôi core.ignorecase. Bạn có thể thử bỏ chọn với:

  git config --unset core.ignorecase

... và xem liệu đầu ra từ git statushoặc git diffkhác nhau.


1

Tôi chỉ đặt filemode = false trong .git / config và nó hoạt động với tôi.

filemode = false

0

Đối với tôi đó là vì 2 máy ảo linux đều được ánh xạ tới cùng một hệ thống tệp gia đình. Một VM đang chạy git-1.7.1, một VM khác đang chạy git-2.14

VM chạy git-1.7.1 sẽ luôn hiển thị 4 tệp như đã thay đổi (thậm chí còn nghĩ rằng nội dung và kết thúc dòng giống hệt nhau).

Khi 'trạng thái git' được chạy trên VM chạy g-2.14, thì cả hai VM sẽ bắt đầu báo cáo kho lưu trữ là sạch. 'trạng thái git' có tác dụng phụ. Nó không phải là một hoạt động bất di bất dịch. Và git-1.7.1 không hiểu thế giới theo cách tương tự như git-2 +.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.