A commit renaming a file with only a change of case breaks crap-clone on Cygwin

[luc-j-bourhis]

I have attached a zipped repo, repo.zip, created on Linux. It consists of the renaming of a file aaa.txt into AAA.txt, plus a change of the content in the process. This was done as follow

mv aaa.txt AAA.txt
cvs add AAA.txt
cvs rm aaa.txt
cvs commit -m 'aaa.txt --> AAA.txt' aaa.txt AAA.txt

As a result, the removal and the addition have exactly the same timestamp. Then I tested crap-clone on both Linux and Cygwin, with the following results:

• crap-cloning it on Linux works fine and result in

  
  % git log --stat                                                  
  commit 61c501b227c8ab45c0ef9eebb986176f0fd96fa9
  Author: luc <luc>
  Date:   Mon Feb 19 14:52:59 2018 +0000
  
  aaa.txt --> AAA.txt
  
  AAA.txt | 2 ++
  aaa.txt | 2 --
  2 files changed, 2 insertions(+), 2 deletions(-)

commit 4fbece18919f1c0d2bd103698746b502896c7a59 Author: luc Date: Mon Feb 19 14:42:33 2018 +0000

Added lowercase filename

aaa.txt | 2 ++ 1 file changed, 2 insertions(+)

- crap-cloning it on Cygwin results in the broken history

% git log --stat
commit 15b4e1fb95e8ebfc16f4dc3db032feb414b7dcef (HEAD -> master) Author: luc Date: Mon Feb 19 14:52:59 2018 +0000

aaa.txt --> AAA.txt

aaa.txt | 2 -- 1 file changed, 2 deletions(-)

commit 4fbece18919f1c0d2bd103698746b502896c7a59 Author: luc Date: Mon Feb 19 14:42:33 2018 +0000

Added lowercase filename

aaa.txt | 2 ++ 1 file changed, 2 insertions(+)

This is obviously caused by the fact that the filesystem is case-insensitive on Cygwin but compounded by the fact that the addition and the removal have the same timestamp.

[rcls]

Ugh, this is a horrible corner case. You will be left in CVS with AAA.txt,v and Attic/aaa.txt,v. It appears that Linux and cygwin CVS servers are treating this situation differently. (Possibly git-fast-import also.) It'll take some experimentation to work out what the correct thing to do here is on all combinations of Linux v. cygwin...

[luc-j-bourhis]

Yes, actually, the CVS histories look different on Linux and Windows in this corner case, so any fix will be a kludge somehow. I started to peer into your code to see whether I can help: crap has moved from a bit of a luxury to an essential tool in my workflow, so I am quite motivated! If you had a one-page document summarising the general architecture, that would be highly appreciated!

[luc-j-bourhis]

I have just found out that one can make Windows case-sensitive, and by extension Cygwin too. After doing that, crap-clone worked beautifully on that troublesome CVS repo. Thus I am not sure there is a point for this issue I opened: as you said, it will be tricky to "fix" crap-clone whereas making Windows case-sensitive involves editing just one entry in the registry (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive shall be 0 instead of the default value of 1).

[rcls]

It's good to hear you found a way past your original problem & that probably is the best solution for your use-case. However, I very much doubt that crap-clone on cygwin matches the behaviour of CVS on cygwin. (At a guess on a case-insensitive platform we should be doing case-insensitive filename comparisons, but it would take some experimentation with CVS to workout the exact behaviour).