Two versions of same line in “git diff”
up vote
1
down vote
favorite
I've encountered strange behavior after switching branches. I've executed git checkout master
, and I immediately had one file marked as modified. I ran git reset --hard
to get rid of it, but to no effect. git diff
gave me output like this:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Info(message);
But when I manually change it back, I get:
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Warn(message);
So git can't decide which one was it. To make it funnier, if I change it to something completely different, I get:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Error(message);
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Error(message);
When I ran git ls-tree -r master | Select-String "myclass.cs"
I got this:
100644 blob 4f8405e28faa09981a3f76775b1693db31b0bdad Project/MYClass.cs
100644 blob cb8ca4c60f10f959422ecc2cbdb91d0e693ea380 Project/MyClass.cs
I see and understand something is off, but I have no idea how did it happen.
I know how to fix it brutal way, removing my local and fetching everything from remote, but I want to know what causes it, and how to fix it properly.
git git-diff
|
show 4 more comments
up vote
1
down vote
favorite
I've encountered strange behavior after switching branches. I've executed git checkout master
, and I immediately had one file marked as modified. I ran git reset --hard
to get rid of it, but to no effect. git diff
gave me output like this:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Info(message);
But when I manually change it back, I get:
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Warn(message);
So git can't decide which one was it. To make it funnier, if I change it to something completely different, I get:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Error(message);
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Error(message);
When I ran git ls-tree -r master | Select-String "myclass.cs"
I got this:
100644 blob 4f8405e28faa09981a3f76775b1693db31b0bdad Project/MYClass.cs
100644 blob cb8ca4c60f10f959422ecc2cbdb91d0e693ea380 Project/MyClass.cs
I see and understand something is off, but I have no idea how did it happen.
I know how to fix it brutal way, removing my local and fetching everything from remote, but I want to know what causes it, and how to fix it properly.
git git-diff
3
Are you by any chance working on windows? What's the output of this? Could you add it to the question?git ls-tree -r master | grep -i class.cs
.
– eftshift0
Nov 22 at 16:21
Was it possible that some settings from your editor cause files (settings) to be changed automatically?
– Christoph
Nov 22 at 17:18
@eftshift0 Yes, I'm currently on Windows. I've added the output to the question, it seems quite strange.
– Sebastian Stasiak
Nov 22 at 21:19
@Christoph I thought that might be the case, so I quit my IDE and edited it in vim, still nothing.
– Sebastian Stasiak
Nov 22 at 21:19
Just try to get a reproducible example. Start to delete stuff until the error is gone. Is this your only project where this happens?
– Christoph
Nov 22 at 21:36
|
show 4 more comments
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I've encountered strange behavior after switching branches. I've executed git checkout master
, and I immediately had one file marked as modified. I ran git reset --hard
to get rid of it, but to no effect. git diff
gave me output like this:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Info(message);
But when I manually change it back, I get:
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Warn(message);
So git can't decide which one was it. To make it funnier, if I change it to something completely different, I get:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Error(message);
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Error(message);
When I ran git ls-tree -r master | Select-String "myclass.cs"
I got this:
100644 blob 4f8405e28faa09981a3f76775b1693db31b0bdad Project/MYClass.cs
100644 blob cb8ca4c60f10f959422ecc2cbdb91d0e693ea380 Project/MyClass.cs
I see and understand something is off, but I have no idea how did it happen.
I know how to fix it brutal way, removing my local and fetching everything from remote, but I want to know what causes it, and how to fix it properly.
git git-diff
I've encountered strange behavior after switching branches. I've executed git checkout master
, and I immediately had one file marked as modified. I ran git reset --hard
to get rid of it, but to no effect. git diff
gave me output like this:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Info(message);
But when I manually change it back, I get:
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Warn(message);
So git can't decide which one was it. To make it funnier, if I change it to something completely different, I get:
diff --git a/Project/MYClass.cs b/Project/MYClass.cs
index 4f8405e..cb8ca4c 100644
--- a/Project/MYClass.cs
+++ b/Project/MYClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Warn(message);
+ Logger.Error(message);
diff --git a/Project/MyClass.cs b/Project/MyClass.cs
index cb8ca4c..4f8405e 100644
--- a/Project/MyClass.cs
+++ b/Project/MyClass.cs
@@ -170,7 +170,7 @@ namespace Project
- Logger.Info(message);
+ Logger.Error(message);
When I ran git ls-tree -r master | Select-String "myclass.cs"
I got this:
100644 blob 4f8405e28faa09981a3f76775b1693db31b0bdad Project/MYClass.cs
100644 blob cb8ca4c60f10f959422ecc2cbdb91d0e693ea380 Project/MyClass.cs
I see and understand something is off, but I have no idea how did it happen.
I know how to fix it brutal way, removing my local and fetching everything from remote, but I want to know what causes it, and how to fix it properly.
git git-diff
git git-diff
edited Nov 22 at 23:38
asked Nov 22 at 16:01
Sebastian Stasiak
751420
751420
3
Are you by any chance working on windows? What's the output of this? Could you add it to the question?git ls-tree -r master | grep -i class.cs
.
– eftshift0
Nov 22 at 16:21
Was it possible that some settings from your editor cause files (settings) to be changed automatically?
– Christoph
Nov 22 at 17:18
@eftshift0 Yes, I'm currently on Windows. I've added the output to the question, it seems quite strange.
– Sebastian Stasiak
Nov 22 at 21:19
@Christoph I thought that might be the case, so I quit my IDE and edited it in vim, still nothing.
– Sebastian Stasiak
Nov 22 at 21:19
Just try to get a reproducible example. Start to delete stuff until the error is gone. Is this your only project where this happens?
– Christoph
Nov 22 at 21:36
|
show 4 more comments
3
Are you by any chance working on windows? What's the output of this? Could you add it to the question?git ls-tree -r master | grep -i class.cs
.
– eftshift0
Nov 22 at 16:21
Was it possible that some settings from your editor cause files (settings) to be changed automatically?
– Christoph
Nov 22 at 17:18
@eftshift0 Yes, I'm currently on Windows. I've added the output to the question, it seems quite strange.
– Sebastian Stasiak
Nov 22 at 21:19
@Christoph I thought that might be the case, so I quit my IDE and edited it in vim, still nothing.
– Sebastian Stasiak
Nov 22 at 21:19
Just try to get a reproducible example. Start to delete stuff until the error is gone. Is this your only project where this happens?
– Christoph
Nov 22 at 21:36
3
3
Are you by any chance working on windows? What's the output of this? Could you add it to the question?
git ls-tree -r master | grep -i class.cs
.– eftshift0
Nov 22 at 16:21
Are you by any chance working on windows? What's the output of this? Could you add it to the question?
git ls-tree -r master | grep -i class.cs
.– eftshift0
Nov 22 at 16:21
Was it possible that some settings from your editor cause files (settings) to be changed automatically?
– Christoph
Nov 22 at 17:18
Was it possible that some settings from your editor cause files (settings) to be changed automatically?
– Christoph
Nov 22 at 17:18
@eftshift0 Yes, I'm currently on Windows. I've added the output to the question, it seems quite strange.
– Sebastian Stasiak
Nov 22 at 21:19
@eftshift0 Yes, I'm currently on Windows. I've added the output to the question, it seems quite strange.
– Sebastian Stasiak
Nov 22 at 21:19
@Christoph I thought that might be the case, so I quit my IDE and edited it in vim, still nothing.
– Sebastian Stasiak
Nov 22 at 21:19
@Christoph I thought that might be the case, so I quit my IDE and edited it in vim, still nothing.
– Sebastian Stasiak
Nov 22 at 21:19
Just try to get a reproducible example. Start to delete stuff until the error is gone. Is this your only project where this happens?
– Christoph
Nov 22 at 21:36
Just try to get a reproducible example. Start to delete stuff until the error is gone. Is this your only project where this happens?
– Christoph
Nov 22 at 21:36
|
show 4 more comments
2 Answers
2
active
oldest
votes
up vote
4
down vote
accepted
Git believes you have two different files in the Project
directory / folder:
MYClass.cs
(uppercaseM
, uppercaseY
, uppercaseC
, lowercaselass.cs
)
MyClass.cs
(uppercaseM
, lowercasey
, uppercaseC
, lowercaselass.cs
)
Git opens each file name separately, writes out the contents for that file, and closes it.
Since you are on Windows, which refuses to make two different files whose names differ only in case, your OS overwrites one of the two files with the other one, leaving only one of the two casings in place. Your OS won't let Git have two files in the work-tree. Git can (and does) have both files in the index, because Git's index is actually a data file, not a directory / folder. Since Git makes its commits out of the index, Git can make new commits that continue to contain two different files whose name differs only in case.
You must update your index so that it contains only one such name, otherwise you're doomed on Windows (and MacOS) to forever fight this problem. The easy way is to do the fixing on a Linux or Unix system, where the index and work-tree stay in sync since the OS can and does create two different files whose name differs only in case.
The hard way is to use git rm --cached
: give it the one name you really want gone. Git will remove that file from the index, without affecting the work-tree at all. Now that the index has the correct case, you can fix the case in the work-tree to match, however one does this on Windows—on other systems, the usual trick is:
mv NameWithCASEISSUE x # change the whole name a lot, using a safe name
mv x NameWithCaseIssue # change it back, using the correct case this time
Now you can compare the index version with the work-tree version and make any adjustments that might be required. Since there's only one index version that will match the work-tree file, regardless of case issues (of which there aren't any now, because you have carefully made the filename cases match), you can get your job done.
The really unfortunate case (if I can use that word :-) ) occurs when you really do want both file names, differing only in case, in the index and in future commits. There are no good tools for dealing with this. It's theoretically possible to build such tools around the git update-index
and git checkout-index
commands, but they do not exist at this time.
add a comment |
up vote
2
down vote
Torek! Why do you steal my answer? :-P
As Torek is explaining (with much greater detail than I would), the problem is that you have two different files for git.... but when git uses Windows FS API, they are both hitting the same file on the FS..... and that explains the whole problem. How do you solve it? If you don't mind fixing the problem moving forward, keep the real file you want with the content you want and delete the other with git rm
and commit. If you want to fix it going back in time, then see where the second file showed up, amend that revision by removing it and rewrite the history on top of it.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
Git believes you have two different files in the Project
directory / folder:
MYClass.cs
(uppercaseM
, uppercaseY
, uppercaseC
, lowercaselass.cs
)
MyClass.cs
(uppercaseM
, lowercasey
, uppercaseC
, lowercaselass.cs
)
Git opens each file name separately, writes out the contents for that file, and closes it.
Since you are on Windows, which refuses to make two different files whose names differ only in case, your OS overwrites one of the two files with the other one, leaving only one of the two casings in place. Your OS won't let Git have two files in the work-tree. Git can (and does) have both files in the index, because Git's index is actually a data file, not a directory / folder. Since Git makes its commits out of the index, Git can make new commits that continue to contain two different files whose name differs only in case.
You must update your index so that it contains only one such name, otherwise you're doomed on Windows (and MacOS) to forever fight this problem. The easy way is to do the fixing on a Linux or Unix system, where the index and work-tree stay in sync since the OS can and does create two different files whose name differs only in case.
The hard way is to use git rm --cached
: give it the one name you really want gone. Git will remove that file from the index, without affecting the work-tree at all. Now that the index has the correct case, you can fix the case in the work-tree to match, however one does this on Windows—on other systems, the usual trick is:
mv NameWithCASEISSUE x # change the whole name a lot, using a safe name
mv x NameWithCaseIssue # change it back, using the correct case this time
Now you can compare the index version with the work-tree version and make any adjustments that might be required. Since there's only one index version that will match the work-tree file, regardless of case issues (of which there aren't any now, because you have carefully made the filename cases match), you can get your job done.
The really unfortunate case (if I can use that word :-) ) occurs when you really do want both file names, differing only in case, in the index and in future commits. There are no good tools for dealing with this. It's theoretically possible to build such tools around the git update-index
and git checkout-index
commands, but they do not exist at this time.
add a comment |
up vote
4
down vote
accepted
Git believes you have two different files in the Project
directory / folder:
MYClass.cs
(uppercaseM
, uppercaseY
, uppercaseC
, lowercaselass.cs
)
MyClass.cs
(uppercaseM
, lowercasey
, uppercaseC
, lowercaselass.cs
)
Git opens each file name separately, writes out the contents for that file, and closes it.
Since you are on Windows, which refuses to make two different files whose names differ only in case, your OS overwrites one of the two files with the other one, leaving only one of the two casings in place. Your OS won't let Git have two files in the work-tree. Git can (and does) have both files in the index, because Git's index is actually a data file, not a directory / folder. Since Git makes its commits out of the index, Git can make new commits that continue to contain two different files whose name differs only in case.
You must update your index so that it contains only one such name, otherwise you're doomed on Windows (and MacOS) to forever fight this problem. The easy way is to do the fixing on a Linux or Unix system, where the index and work-tree stay in sync since the OS can and does create two different files whose name differs only in case.
The hard way is to use git rm --cached
: give it the one name you really want gone. Git will remove that file from the index, without affecting the work-tree at all. Now that the index has the correct case, you can fix the case in the work-tree to match, however one does this on Windows—on other systems, the usual trick is:
mv NameWithCASEISSUE x # change the whole name a lot, using a safe name
mv x NameWithCaseIssue # change it back, using the correct case this time
Now you can compare the index version with the work-tree version and make any adjustments that might be required. Since there's only one index version that will match the work-tree file, regardless of case issues (of which there aren't any now, because you have carefully made the filename cases match), you can get your job done.
The really unfortunate case (if I can use that word :-) ) occurs when you really do want both file names, differing only in case, in the index and in future commits. There are no good tools for dealing with this. It's theoretically possible to build such tools around the git update-index
and git checkout-index
commands, but they do not exist at this time.
add a comment |
up vote
4
down vote
accepted
up vote
4
down vote
accepted
Git believes you have two different files in the Project
directory / folder:
MYClass.cs
(uppercaseM
, uppercaseY
, uppercaseC
, lowercaselass.cs
)
MyClass.cs
(uppercaseM
, lowercasey
, uppercaseC
, lowercaselass.cs
)
Git opens each file name separately, writes out the contents for that file, and closes it.
Since you are on Windows, which refuses to make two different files whose names differ only in case, your OS overwrites one of the two files with the other one, leaving only one of the two casings in place. Your OS won't let Git have two files in the work-tree. Git can (and does) have both files in the index, because Git's index is actually a data file, not a directory / folder. Since Git makes its commits out of the index, Git can make new commits that continue to contain two different files whose name differs only in case.
You must update your index so that it contains only one such name, otherwise you're doomed on Windows (and MacOS) to forever fight this problem. The easy way is to do the fixing on a Linux or Unix system, where the index and work-tree stay in sync since the OS can and does create two different files whose name differs only in case.
The hard way is to use git rm --cached
: give it the one name you really want gone. Git will remove that file from the index, without affecting the work-tree at all. Now that the index has the correct case, you can fix the case in the work-tree to match, however one does this on Windows—on other systems, the usual trick is:
mv NameWithCASEISSUE x # change the whole name a lot, using a safe name
mv x NameWithCaseIssue # change it back, using the correct case this time
Now you can compare the index version with the work-tree version and make any adjustments that might be required. Since there's only one index version that will match the work-tree file, regardless of case issues (of which there aren't any now, because you have carefully made the filename cases match), you can get your job done.
The really unfortunate case (if I can use that word :-) ) occurs when you really do want both file names, differing only in case, in the index and in future commits. There are no good tools for dealing with this. It's theoretically possible to build such tools around the git update-index
and git checkout-index
commands, but they do not exist at this time.
Git believes you have two different files in the Project
directory / folder:
MYClass.cs
(uppercaseM
, uppercaseY
, uppercaseC
, lowercaselass.cs
)
MyClass.cs
(uppercaseM
, lowercasey
, uppercaseC
, lowercaselass.cs
)
Git opens each file name separately, writes out the contents for that file, and closes it.
Since you are on Windows, which refuses to make two different files whose names differ only in case, your OS overwrites one of the two files with the other one, leaving only one of the two casings in place. Your OS won't let Git have two files in the work-tree. Git can (and does) have both files in the index, because Git's index is actually a data file, not a directory / folder. Since Git makes its commits out of the index, Git can make new commits that continue to contain two different files whose name differs only in case.
You must update your index so that it contains only one such name, otherwise you're doomed on Windows (and MacOS) to forever fight this problem. The easy way is to do the fixing on a Linux or Unix system, where the index and work-tree stay in sync since the OS can and does create two different files whose name differs only in case.
The hard way is to use git rm --cached
: give it the one name you really want gone. Git will remove that file from the index, without affecting the work-tree at all. Now that the index has the correct case, you can fix the case in the work-tree to match, however one does this on Windows—on other systems, the usual trick is:
mv NameWithCASEISSUE x # change the whole name a lot, using a safe name
mv x NameWithCaseIssue # change it back, using the correct case this time
Now you can compare the index version with the work-tree version and make any adjustments that might be required. Since there's only one index version that will match the work-tree file, regardless of case issues (of which there aren't any now, because you have carefully made the filename cases match), you can get your job done.
The really unfortunate case (if I can use that word :-) ) occurs when you really do want both file names, differing only in case, in the index and in future commits. There are no good tools for dealing with this. It's theoretically possible to build such tools around the git update-index
and git checkout-index
commands, but they do not exist at this time.
answered Nov 23 at 0:59
torek
180k17231312
180k17231312
add a comment |
add a comment |
up vote
2
down vote
Torek! Why do you steal my answer? :-P
As Torek is explaining (with much greater detail than I would), the problem is that you have two different files for git.... but when git uses Windows FS API, they are both hitting the same file on the FS..... and that explains the whole problem. How do you solve it? If you don't mind fixing the problem moving forward, keep the real file you want with the content you want and delete the other with git rm
and commit. If you want to fix it going back in time, then see where the second file showed up, amend that revision by removing it and rewrite the history on top of it.
add a comment |
up vote
2
down vote
Torek! Why do you steal my answer? :-P
As Torek is explaining (with much greater detail than I would), the problem is that you have two different files for git.... but when git uses Windows FS API, they are both hitting the same file on the FS..... and that explains the whole problem. How do you solve it? If you don't mind fixing the problem moving forward, keep the real file you want with the content you want and delete the other with git rm
and commit. If you want to fix it going back in time, then see where the second file showed up, amend that revision by removing it and rewrite the history on top of it.
add a comment |
up vote
2
down vote
up vote
2
down vote
Torek! Why do you steal my answer? :-P
As Torek is explaining (with much greater detail than I would), the problem is that you have two different files for git.... but when git uses Windows FS API, they are both hitting the same file on the FS..... and that explains the whole problem. How do you solve it? If you don't mind fixing the problem moving forward, keep the real file you want with the content you want and delete the other with git rm
and commit. If you want to fix it going back in time, then see where the second file showed up, amend that revision by removing it and rewrite the history on top of it.
Torek! Why do you steal my answer? :-P
As Torek is explaining (with much greater detail than I would), the problem is that you have two different files for git.... but when git uses Windows FS API, they are both hitting the same file on the FS..... and that explains the whole problem. How do you solve it? If you don't mind fixing the problem moving forward, keep the real file you want with the content you want and delete the other with git rm
and commit. If you want to fix it going back in time, then see where the second file showed up, amend that revision by removing it and rewrite the history on top of it.
edited Nov 23 at 7:14
answered Nov 23 at 4:14
eftshift0
4,304817
4,304817
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434626%2ftwo-versions-of-same-line-in-git-diff%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Are you by any chance working on windows? What's the output of this? Could you add it to the question?
git ls-tree -r master | grep -i class.cs
.– eftshift0
Nov 22 at 16:21
Was it possible that some settings from your editor cause files (settings) to be changed automatically?
– Christoph
Nov 22 at 17:18
@eftshift0 Yes, I'm currently on Windows. I've added the output to the question, it seems quite strange.
– Sebastian Stasiak
Nov 22 at 21:19
@Christoph I thought that might be the case, so I quit my IDE and edited it in vim, still nothing.
– Sebastian Stasiak
Nov 22 at 21:19
Just try to get a reproducible example. Start to delete stuff until the error is gone. Is this your only project where this happens?
– Christoph
Nov 22 at 21:36