I have been transferring a Visual SourceSafe repository (2000 unique files, 
with their version history in total something like 20000 files) to Git. 
Used a tool vss2git. After the transfer I recompiled the projects, and of 
17 files the latest version was not in the repository. Later on I 
discovered similar problems with binary files (icon and cursor bitmaps that 
typically keep the same size). Digging in the very detailed vss2git log it 
turned out that the git add command had failed in these cases. Typically, 
all these files have exactly the same size but different contents as their 
predecessor. 
So I created a minimal sample case of this exact problem, that's the 
zipfile I uploaded. Again, the same thing happened. It could be that the CR 
to CRLF conversion has to do with it. Or the case-insensitivity of 
filenames. I use the default Git configuration of msysGit. 

So it looks more like a Git bug than a hash clash.

I will try the testcase tomorrow on an other computer with a slightly 
different Git version. I will also download the latest Git version. I will 
try to make a log of a bash session where you can see it fail.

Thanks for now!

Joost

On Friday, January 23, 2015 at 6:11:54 PM UTC+1, J66st wrote:
>
> Working with git now for a few weeks, and trying to move my Visual 
> SourceSafe repositories to git.
>
> I am encountering a weird problem. I have set up a small example repo (see 
> the attached zipfile).
>
> Containing a single file dixilinkerr.h. There are three versions of this 
> file.
>
> v1: Contains a #pragma message line, and a #define CAT_DIXILINK_ERR
> v2: Edit: the #pragma message line is removed.
> v3: Edit: the symbol CAT_DIXILINK_ERR is replaced by EXCPCAT_DIXILINK
>
> Watching the repository and working directory in the current state:
>
> *git status*:
> nothing to commit, working directory clean.
>
> *git log* shows 2 commits: v1 and v2.
>
> *gitk* shows 2 commits:
> The first one in the root commit is v1.
> But the second one shows different result depending on the chosen view:
> *gitk Patch* view: the last commit is a patch from v1 to v3! (So 
> bypassing v2!!)
> *gitk Tree* view: the last commit is v2
> THIS IS WEIRD!
>
>
> *git show HEAD:dixilinkerr.h*
> Shows v2.
>
> So the strange thing is:
> v3 is not really in the repository. If you check out the latest version 
> you get v2.
>
> v3 is in my working directory.
> But git does not see any changed files, and the index is empty. Git commit 
> won't add the file.
>
> So the file is kind of halfway checked in...
>
> I ran into this problem several times when checking in thousands of files 
> using a script.
> It seems to happen only when the file size of the two last versions of a 
> file are equal but the contents differ.
> In the above example the v2 and v3 versions of the file have the same size.
>
> I am using msysgit version 1.9.0 on Windows 7.
>
> Is this a bug or am I missing something? 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to