Community
Participate
Working Groups
I had three files that were changed in git. I staged one. Decided to unstage it. - couldn't find a single "unstage" command. Can you only unstage all? - I pressed unstage all and ended up with a list of *all* the files from the repo as unstaged. Refreshed the page and it was still there. Panicked. Went to Git GUI and pressed "rescan". It showed only the three files. Reloaded git-status. Now it shows only the three files. Perhaps for M6 we should consider an "unstage" command to avoid this scenario?
Susan , there is no support from the server yet for unstaging sigle file . Regarding the "all file unstaged" issue , could not reproduce here but I will investigate further.
I just pulled the server again and restarted it. Same problem. Rescanning the files in Git Gui corrects it, otherwise all files are listed. I'm on Win7, using msysgit
Is your top-level folder (project) in Orion the same directory as the Git repository you are using? I.e. if you have a local directory "org.eclipse.orion.client" containing ".git" and "bundles", is that the directory you link to from Orion? Tomek, would this be a possible cause for the behaviour Susan is seeing?
And yes, it's a known limitation that you can only unstage all (but it shouldn't show every single file as modified).
I am routing this to Tomasz. Susan and I spent some time tackling it down. She created a freshh link to her git repo and I tried on her server as well. Not sure why server responded all the files. I even tried to view the diff and there was no real diff.
additional info : I tried same steps on my server (pulled the latest code ) and couldn't reproduce.
(In reply to comment #3) > Tomek, would this be a possible cause for the behaviour Susan is seeing? (In reply to comment #5) > Not sure why server responded all the files. > I even tried to view the diff and there was no real diff. The first thing that came to my mind was that line endings must have changed from CRLF to LF or vice versa.
I'm trying to reproduce it on my side... In the meantime, Susan, I assume you used msysgit to create the clone, right? Do you have core.autocrlf option on or off? Did "git diff" and "git diff -w" give same results?
I'm able to reproduce, even better, I've got a failing test for that case. Mixing different line endings (CRLF and LF) across files and having the core.autocrlf option set to "true" gave me a similar result - after unstaging (all) I got an extra file marked as modified, a file which I didn't touch at all. What is werid, if I do "git status" in bash just before I ask for the same thing using REST API the test passes. Trying to figure out what's going on...
I think I've got it: A clone created with CloneCommand will have auto.crlf set to "false" on the repository level. On the other hand, If you clone the same repo with msysgit it will not set that option and use the global setting, which I guess is set to "true". The bad news is that JGit doesn't support the core.autocrlf option[1], so we cannot make it return the same result as msysgit/native git. Workaround: "git config --global core.autocrlf false" [1] bug 301775
(In reply to comment #10) > I think I've got it: A clone created with CloneCommand will have auto.crlf set > to "false" on the repository level. On the other hand, If you clone the same > repo with msysgit it will not set that option and use the global setting, which > I guess is set to "true". The bad news is that JGit doesn't support the > core.autocrlf option[1], so we cannot make it return the same result as > msysgit/native git. > > Workaround: "git config --global core.autocrlf false" > > [1] bug 301775 Tomasz , it would be nice if we can add this to the git-clone section in wiki. People starting to use our git features may hit the same issue by chance.
Until JGit guys fix bug 301775 I will turn autocrlf off (set it to false) for the time of creating a Git Status response and when done set it back to the original value -- b6c6e3e2d8d89ba8416508330a7d251084eef367.
(In reply to comment #12) > Until JGit guys fix bug 301775 I will turn autocrlf off (set it to false) for > the time of creating a Git Status response and when done set it back to the > original value -- b6c6e3e2d8d89ba8416508330a7d251084eef367. This workaround isn't quite right. When getting the preference it does: autocrlf = config.getString(...); But then in the finally block it does: boolean p = Boolean.parseBoolean(autocrlf); config.setBoolean(...); The problem is that "autocrlf" is not a boolean. It supports values of "true", "false", or "input". A value of "input" will be converted to "false" in this case. More deeply, we are bashing this value for the "status" command, but not for other commands. It seems like this means the extra files will be hidden from our status view, but stage/unstage/commit will operate on them anyway. Overall this feels very unsafe. We are going to revert this workaround, and instead document the other workaround... People using a mixture of JGit and non-JGit clients for git should disable autocrlf until the JGit bug is fixed: "git config --global core.autocrlf false"
I agree the fix sounds risky and I think the right fix is at the JGit level. I tried the workaround. Of course the first time you change the setting, the git client will show all files as changed (as did git-status). I had to revert all the changes and after that, the git client and Orion git-status operate as I expect. > We are going to revert this workaround, and instead > document the other workaround... People using a mixture of JGit and non-JGit > clients for git should disable autocrlf until the JGit bug is fixed: "People using a mixture of JGit and non-JGit clients" really means "anyone who downloads Orion to run locally and runs a typical git client." So we need to make sure the warning is prominent in the "Getting the code" wiki or anywhere else where we talk about localhost usage. If I don't know/care that Orion uses JGit, I won't understand the explanation. So I suggest wording like: ------------ Orion git support is implemented using JGit. A bug in JGit (bug 301775) prevents the Orion client from showing the correct git status when core.autocrlf is set to true. If you are using a git client other than JGit, you must set core.autocrlf to false in order for the Orion git status to operate properly. "git config --global core.autocrlf false"
We should also say: "If you need to run with core.autocrlf set to true, you can still use the Orion git status GUI, but you should always run your git client's status command before using the Orion git status GUI." (someone with more git knowledge can explain why this works, but this is what I've been doing.)
I've marked the GitResetTest.testResetAutocrlfTrue() test to be ignored, so all tests pass again -- 144f8cce6201f5117dd4416511d704ba53477960.
Simon showed me the similar issue today :unchanged files are listed as unstaged. It prevented him from self-hosting. If JGit can not fix our depending issue we may want to figure out a way on our side. Otherwise I think it is a show stopper for June release.
I'll try to find some time and look at it this week.
(In reply to comment #17) > Simon showed me the similar issue today :unchanged files are listed as > unstaged. It prevented him from self-hosting. A bit more info... I have core.autocrlf=false set but I am still hosed. What I did was link my org.eclipse.orion.client folder. My git repo was created by using the regular bash shell git commands with cygwin. If I use the command-line my git status looks fine. I've tried a new checkout, switching branches, running git gc, a hard git reset but am still broken in the webui.
while you are looking into this, please read bug 344038. I know nothing at all about the git implementation but my gut tells me that this is a related symptom because it is also of the variety of "my command line created git repo was okay and then it was hosed from an Orion point of view."
(In reply to comment #17) > If JGit can not fix our depending issue we may want to figure out a way on our > side. Otherwise I think it is a show stopper for June release. AFAIK linking to a clone in local file system was supposed to be a short term solution. If so, the only way to work with a git repository is to clone one in Orion. From what I can see on both bugs (this one and bug 344038) this would prevent Simon and Susan from seeing all those nasty things. I'm not saying it's not a issue, but I don't think it's 'critical'. I'm still trying to understand what's going on.
(In reply to comment #19) > I have core.autocrlf=false set but I am still hosed. I will need exact steps for this. I've followed your description and it worked fine for me: 1. set global core.autocrlf to false 2. cloned a repo with msysgit 3. linked it to a project in Orion 4. modified a file 5. went to Git Status page 6. staged it, unstaged all => single file in the Unstaged section, good If I go through the same steps but having autocrlf set to true (default) I'm seeing the same thing as in comment 0 (already confirmed in comment 9).
It's been over a week so I'm marking this one as "worksforme". If it's reproducable for you guys, please reopen and provide the exact steps you used to produce the problem.
Please ignore my last comment, the issue for which Susan has filed this bug is still valid. I read couple of last comments and closed the bug, sorry. The "worksforme" solution applies only to Simon's comment 19. I'm reopening the bug, clearing Target Milestone at the same time, as it doesn't seem to be as urgent as it used to be. Sorry for the noise.
Mark hit the same issue today : He cloned git://github.com/mamacdon/mamacdon.github.com.git by git bash. He changed a file and used stage all to stage it. He saw dozens of files in the staged area. I verified that he had core.autocrlf as true. So I set "git config --global core.autocrlf false" and cloned the repo. Everything was fine then. Hopefully this can be another test case when either Jgit fixes bug 301775 or we provide a patch.
Is this still an issue?
I haven't seen this for long time.
