Why does "git rebase" leave opposite sets of modifications in the stage and the working copy?

Question

I'm using git-svn as an svn client. From time to time I encounter the following issue.

1. I start with a couple of commits in my local git branch, a empty stage and a clean working copy.

2. I type "git svn rebase" in windows command line to fetch the team's modifications and put my commit after them to keep a linear history (this is required to use git-svn)

3. Everything goes fine, team's content is fetched and my commits are rebased after then, but...

   I end up with modifications in the working copy, and modified files in the stage, and the modifications of the working copy are the exact oposite of the modifications in the stage.

I Usually work around this by just unstaging everything that's in the stage, which reverts the modifications in the working copy, which is fine, but I would really like to understand what's happening here.

Question: Is that a bug, or is it something that I don't understand with git rebase?

Note: I had the issue while using "git svn fetch" and "git rebase" later.

Note: I use git on windows with a large svn repository (10000+ files, 150000+ revisions), and I also use git-extensions. Edit: I use it only explore the repository and commit. I do anything else from windows command line.

Edit: As requested by one of the comment, here are two screenshot to help understand the problem. The first is the content of the working copy, the second is the content of the stage. You can easily see the both are the exact oposite:

Working copy:

Stage (reverts working copy modifications, very visual: same image, red and green are swapped):

Edit: I just reproduced the issue in a very simple case: My commit modifies only one file, very few new commits were fetched during the "git svn rebase", and none of them affected the modified file. I checked with "gitk --all". It says exactly the same thing than git-extensions and "git status" Here is the output of gitk. We see from bottom to top:

• The last 3 lines are the 3 commits tha were fetch when rebasing. None of them touches my file.
• The 3rd line from top show my commit after rebase: it's all good, it adds what it's supposed to add and removes what it's supposed to remove.
• The 2nd line shows the content of the index: it contains modifications that revert my commit
• The 1st line shows the content of the working copy: it contains the same modifications that my commit does, IE reverts the modification in the index.

Edit: Here is the content of my .git dir after a "git svn rebase" where the problem occured:

17/02/2012  04:57                 0 ArmuazEm5Z
05/04/2012  02:28                 0 BeMzRLwWcu
06/11/2012  14:37                90 COMMIT_EDITMSG
01/11/2012  15:42               628 config
15/02/2012  04:21                73 description
16/02/2012  13:22                 0 fuMhUevkYu
05/11/2012  15:53         1 703 279 gitk.cache
05/07/2012  03:49                 0 gJfUbdRuG9
06/11/2012  14:42                23 HEAD
11/07/2012  03:14    <DIR>          hooks
21/02/2012  03:22                 0 II5HPacSJd
06/11/2012  14:42         5 439 960 index
15/10/2012  13:18    <DIR>          info
16/02/2012  08:16                 0 jerS1GtBYS
17/02/2012  04:57                 0 Kg64sq9pzS
15/02/2012  23:36                 0 lbe0yALJYy
15/10/2012  13:17    <DIR>          logs
19/10/2012  16:58    <DIR>          objects
06/11/2012  14:42                41 ORIG_HEAD
25/10/2012  11:02             2 795 packed-refs
05/07/2012  03:49                 0 PpxYa5z0Hc
02/11/2012  10:00    <DIR>          refs
15/02/2012  23:36                 0 sm6ociDGGF
06/11/2012  14:42    <DIR>          svn
21/02/2012  03:22                 0 vEqtL0Yiqd
05/04/2012  02:28                 0 VFwn3laTEV
16/02/2012  13:22                 0 XYoiLqY5BM
16/02/2012  08:16                 0 z9vL8lRT7t
              22 File(s)      7 146 889 bytes
               6 Dir(s)  54 105 219 072 bytes free

Edit: If you are interested in tracking this issue, I reported a bug on [email protected] mailing list with "[git-svn] [bug report] Index in strange state after git svn rebase" in the subject.

Falzetta

sounds like a nightmare. Anyway of getting rid of SVN? – Cockspur

@AdamDymitruk This is a long process in a 500+ people company... I use git-svn while waiting for the change. I'm quite happy with it: quick branch creating, fast branch switching, multiple working copies, great merging capabilities... Just a few issues sometimes. – Falzetta

can you post a screenshot of gitk that illustrates what is happening? with the branches and diff and sensitive stuff blanked out etc. I suspect that your working tree is not clean even before the rebase (you can check by git status) – Pavkovic

@Pavkovic I do that next time I encounter the issue... But I don't think that it's a possibility. I always make sure to have a clean working copy before doing any rebase. – Falzetta

Uhm, can you reproduce that from the command line without using Git Extensions? Also, you keep mentioning git rebase; are you using git rebase or git svn rebase (there is an important difference)? – Parkland

@Parkland I encountered this issue both with "git svn rebase", or "git svn fetch" followed by "git rebase". git-extensions is often open, but I use it only to view the state of my repository and to commit. I always type other commands in the windows command shell (window's one, not git-extension shell) because I find it more convenient. – Falzetta

do you get the same results when using gitk --all to view the graph (both commits and the diffs)? I'm interested in the commits that lead up to what you see, if the graph indicates something is "removed/---" (when it has actually been "added/+++"), one would expect that an earlier commit to have "added" it already. See if you can find such a commit – Pavkovic

@Pavkovic I just had the issue again. gitk says exactly the same thing than git-extensions. And this time the issue is very well isolated as: my commit modifies only one file, very few new commits were fetched during the "git svn rebase", and none of them affected the modified file. My commit is excatly what I want it to be after the rebase, it's just the content of the index and working copy that are messed up. – Falzetta

@Pavkovic I just added explanations and screenshot related to gitk in the question. – Falzetta

Can you show the contents of your .git directory after doing a rebase when you have this problem? – Mandeville

This appears to be related to autocrlf. code.google.com/p/msysgit/issues/detail?id=83 – Proportion

@NickBerardi good pick... It's just that compelte reiinstall reset this setting. Thanks for the info – Falzetta

Answer 1

This appears to be a bug. If your working directory and index are clean before a rebase, they should be clean after rebase; or you should get a merge conflict and the opportunity to clean it up and continue the rebase.

It looks like for some reason, your index is being left stale after applying your local modifications.

Basically, there are three main views of the current state of the repository. There is the HEAD commit, which is the state of the repository as of the last commit, and what your next commit will be a child of. This is being updated properly during your rebase; HEAD is now your local commit, rebased on top of what you got from the upstream repository.

There's the index, which is supposed to contain a view of what the state of your next commit will be. This seems to be where the problem is. After a successful rebase from a clean tree, the index should appear to have the same view of the repository as HEAD, but it appears to be getting a stale view, of what the upstream repository contains. It looks like it isn't being updated after applying your local patches on top of the upstream repository.

And there's your working copy; the actual files on your disk. For some reason, when you are doing the rebase, the head commit is being updated properly, and the working tree is being updated properly (or is being left alone), but the index is left in a state that refers to the origin commit that you are rebasing onto. This means that if you compare the index to your rebased commit, it looks like you have reverted your changes, and if you compare your working copy to your index, it looks like you have added them back again.

A few things to check:

1. Can you show us the contents of your .git directory after such a problematic rebase? Just a list of the files at the top level of .git would be helpful. Actually, a full listing, including filenames, modification dates, and permissions might give a little more information.
2. Are you using this over any kind of networked filesystem, or anything else odd? Networked filesystems sometimes have issues in which files will be left stale; I wonder if that is happening to you.
3. What version of Git are you using?

Mandeville

Thank you so much for your attention. 1 I'll post that next time I get the issue. 2 My git repository is on a good old NTFS file system on C:\, but my user's home directory, which contains .gitconfig is on a network drive (corporate computer configuration) 3 git --version outputs "git version 1.7.10.msysgit.1" I installed a bundle containing git-extension and git from git-extensions site. I did not know that they packaged their own version of git. I just realized that while checking the version. I will try to install a regular version of git and see if I still have the issue. – Falzetta

@SamuelRossille Git Extensions just packages the standard Git for Windows (msysgit), so it’s identical to the one, you would install manually. – Parkland

I edited the question to add the contents of the .git directory while the problem occurred. I'm starting to seriously think it's a bug, but I cannot find in in the git mailing list archive. I think i'll report it. – Falzetta

@SamuelRossille Nothing I see in there stands out all that much. The timestamp on your index appears to be correct. I wonder about all the files named like "fuMhUevkYu"; those aren't normal for a .git directory. Do you know what process is writing those? They appear to be empty; can you move them out of the way? Another thing to check is whether you're running anti-virus software; sometimes those can prevent writing a file if they get a false-positive against a virus signature. Can you turn off any anti-virus software? If none of that works, I would recommend reporting a bug. – Mandeville

@BrianCampbell I did not mention it, but i Tought about the antivirus, and I reproduced the issue with the antivirus off. I filed a but on git with a link to this question. Hopefully they will solve the problem. Other people from my company saw the question and reported to have the same issue, so I think it's definitely a bug. – Falzetta

That was indeed a bug. Issue disappeared after upgrading to Git Extensions 2.43 - Git 1.8 – Falzetta

@SamuelRossille Glad to hear it! – Mandeville

I do not believe that this issue has been resolved or that it's related to svn, though it is interesting that moving to 1.8 made it disappear for you. My organization is running into this and other index-related issues during rebases. I've made a post to the msysGit group asking for help: groups.google.com/d/msg/msysgit/dj9uVz3vXNw/3smFmyuato4J . – Beard