Re: [PATCH 1/2] init-db.c: honor case on case preserving fs
On Sat, Feb 1, 2014 at 1:14 PM, Reuben Hawkins reuben...@gmail.com wrote: Most case-insensitive filesystems are case-preserving. In these filesystems (such as HFS+ on OS X) you can name a file Filename.txt, then rename the file to FileName.txt. That file will be accessible by both filenames, but the case is otherwise honored. We don't want to have git ignore case on these case-preserving filesystem implementations. Actually, we want to ignore case on ANY case-insensitive file system whether it is a case-preserving or not. Let's suppose we have a central repository where Filename.txt is renamed as FileName.txt. Now a user pulls changes from that repository on Windows. With core.ignorecase = true, everything works perfectly: $ git pull remote: Counting objects: 3, done. remote: Total 2 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. From z:/shared/test2/ 3d885e6..ce5deef master - origin/master Updating 3d885e6..ce5deef Fast-forward Filename.txt = FileName.txt | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename Filename.txt = FileName.txt (100%) $ ls FileName.txt Now, if you try to do the same thing with core.ignorecase = false, you get this: $ git pull remote: Counting objects: 3, done. remote: Total 2 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. From z:/shared/test2/ 3d885e6..ce5deef master - origin/master Updating 3d885e6..ce5deef error: The following untracked working tree files would be overwritten by merge: FileName.txt Please move or remove them before you can merge. Aborting I have tested this with git version 1.8.3.msysgit.0, but I don't think it is any different with the latest version. This fixes a problem where if you import an hg repository, using git-remote-hg, Perhaps, it fixes that case, but it breaks a far more common case. So I believe that git-remote-hg should be corrected and not init-db.c Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] init-db.c: honor case on case preserving fs
On 2/2/14, Reuben Hawkins reuben...@gmail.com wrote: This is a separate issue which core.ignorecase is sweeping under the rug. When you get this error message, do an 'ls' and you'll see there isn't an untracked file called 'FileName.txt'. There is, however, a tracked file called 'Filename.txt'. Because there aren't really any untracked files, the merge should be able to complete without overwriting anything. I am afraid but it is exactly the same issue, because it never happens on any case-sensitive system. IIRC, Git stats 'FileName.txt' to verify whether it exists or not, and the file system tells that this file exists, because it ignores case. So the option is called 'ignorecase'. No one meant this option to be about whether the file system preserves case or not, because Git does not care about it and assumes that on any case-insensitive filesystem, the right case is in the index, which is usually better, because otherwise people can often change filenames inadvertently. I don't know much about importers, but I have looked at the source code of fast-import.c and I do not see ignore_case there, though it may affect it indirectly through some functions that it uses. AFAIK, fast-import does not rely on the filesystem, it should always work with ignorecase=false. Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
On Tue, Jul 16, 2013 at 7:54 AM, Mark Levedahl mleved...@gmail.com wrote: I see no difference in the above. (Yes, I checked multiple times that I was using different executables). Are you sure that you set core.filemode to false before testing? If you have core.filemode set to true then you _always_ use Cygwin stat, so it does not make any difference for you. Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On Sat, Dec 22, 2012 at 4:31 PM, Toralf Förster toralf.foers...@gmx.de wrote: /me still wonders whether this race condition is a feature or an issue in GIT - b/c it means that 2 different people cloning the same repository get different results. The problem is that Git assumes that conversion from git to the worktree and back produces the same result. Unfortunately, this assumption is not enforced anywhere and when it is broken by editing .gitattributes, it may be difficult to notice that immediately unless you do that trick with removing the index and git reset. Perhaps, it would be better if git considered that timestamps on all files changed if .gitattributes is changed, so it would check all files for consistence, then anyone who edits .gitattributes will be forced to fix the file ending to be consistent. Anyway, when this underlying assumption is broken, it is easy to get that race, because git checks only those files for modification that have its timestamp equal or newer than the index. (The equal timestamp are inspected for modification, because the timestamp resolution can be 1 second on some systems.) When you check out some version, some of files are going to have an older timestamp than the index (and thus they are not inspected for modification) but those that have the same timestamp as the index are inspected for modification. Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Missing Refs after Garbage Collection
Hi, On Sat, Dec 22, 2012 at 5:41 AM, Earl Gresh egr...@codeaurora.org wrote: Is anyone familiar with git gc deleting valid references? I'm running git version 1.7.8. Have there been any patches in later git releases that might address this issue ( if it is a git problem )? I have not seen any relevant changes in git. I have looked at the code, and what git-gc is running git pack-refs --all --prune, which is very careful in packing and fsyncing the new file with all packed references before deleting anything. Only those references that were packed can be deleted. Also, it does not matter whether a reference is valid or not, or whether it is stored in refs/changes or in some other place, like refs/heads. So if references were really lost as you described, I think other people would notice that by now. The only plausible explanation that comes to my mind now is that file creation using O_EXCL is not atomic on your system, then the lock did not work and one process could overwrite packed references created by another. Dmitry -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
