Pulling without committing first seems to revert changes

[BraunTom]

We changed our Readme (commit: 92141102d52436a766aa5e8cd77ee0450d902bd2) and no later than 3 commits later (we are not sure which) the changes got reverted.

Github does not display the reverted changes though, therefore it is sometimes very difficult to notice, whether any changes were reverted. We only noticed it, because the README is so prominent in our repository.

This issue has happened multiple times during our development. If you have changes in your image and pull before committing the changes, then the changes of the pull are not checked out correctly, therefore committing will revert the pulled changes.

[j4yk]

You did not give a link to the repository, so I can only guess what it is from the description. So far, I assume it is a duplicate of #53. Because merging of Git trees has not been implemented yet, files that are not managed via Sqout/the Git Browser, such as the readme file, are overlooked during merges. Probably someone in your team pulled the changes to the readme, produced a merge in the process (no fast forward) and that merge did not include the remote changes to the readme. So from the perspective of the remote branch, it looks like the merge reverts the changes made to the readme. Does that sound accurate?

Anyway, the Smalltalk code is merged correctly. The issue only applies to extra files, although it is still annoying enough with these.