Git在Windows上与重复文件合并 [英] Git merge on Windows with duplicate files

问题描述

我在将本地分支与远程同步时遇到问题，我知道为什么，并且有一种解决方法-但想知道是否有更好的解决方案.

I'm having problem synchronizing a local branch with a remote, I know why and have a work-around - but would like to know if there is a better solution.

1. 用于共享的gh-pages分支；因此分支上没有积极的发展
2. 我在Windows上工作(无法轻松激活Posix支持的区分大小写的文件名).
3. 存储库包含两个文件，只是文件名大小写不同，即它们将相互覆盖！
4. 我要添加一些其他文件
5. 并将此分支与远程同步(使用合并/拉动).

1. It's for a shared gh-pages branch; so no active development on the branch
2. I work on Windows (and cannot easily activate Posix-support for case-sensitive file-names).
3. The repository contains two files that only differ in case for the file names, i.e. they will over-write each other!
4. I want to add some other files
5. And synchronize this branch with the remote (using merge/pull).

第2项和第3项意味着仅签出文件会产生更改，因为一个大小写变量会覆盖另一个.

Items 2 and 3 mean that just checking out the files creates a change, as one case-variant over-writes the other.

但是，仍然可以通过创建新的本地分支，暂存和提交新文件并忽略警告来处理1-4.

However, items 1-4 can still be handled by creating a new local branch, staging and committing the new files - and ignoring warnings.

但是合并/拉出等失败；因为存在大小写冲突的文件会引起问题.

But merge/pull etc fail; as the files with case-conflicts cause problems.

删除 local 分支，然后基于远程对象创建一个新分支(假定没有本地更改).

Delete the local branch and then create a new one based on the remote (assuming there are no local changes).

推荐答案

您无需删除任何分支，但是您必须小心使用工作树.

You need not delete any branch but you will have to be careful with your working tree.

请记住，Git实际使用的是Git的 index ，无论是检出任何现有的提交，还是进行任何 new 提交. Git也将此实体称为暂存区，以反映其在进行新提交中的作用，并且-尽管这些天您大多将其视为标志--cached- cache ，反映出索引在Git快速运行中的作用.

Remember that what Git actually uses, both to check out any existing commit, and to make any new commit, is Git's index. Git also calls this entity the staging area, reflecting its role in making new commits, and—though these days you mostly see this as a flag, --cached—the cache, reflecting the index's role in making Git go fast.

存储在索引中的文件是区分大小写的，因此，例如，Git的索引能够容纳两个分别命名为a/readme.txt和A/README.TXT的文件.请注意，索引中的文件以使用正斜杠的路径名表示，而a/readme.txt是文件名-索引中没有文件夹，而文件名中带有斜杠.

Files stored in the index are case-sensitive, so Git's index is capable of holding two separate files named a/readme.txt and A/README.TXT, for instance. Note that files in the index are represented with path names that use forward slashes, and that a/readme.txt is a file name—there are no folders in the index, just files with embedded slashes in their names.

索引为 的文件以Git的内部格式存储.这对您没有用:这些文件采用压缩的只读Git数据格式.因此，Git将每个此类文件扩展为一个普通的日常读写文件.该普通的读/写文件进入一个文件夹，并具有一个普通的日常文件名.但这意味着，当Git编写a/readme.txt(需要在其中创建一个名为a的文件夹和一个名为readme.txt的文件)和A/README.TXT(这都需要创建一个名为A的文件夹和一个文件)时，在 that 中名为README.TXT的情况下，您会遇到名称冲突.实际上只有一个文件夹和一个文件被创建.

The files that are in the index are stored in Git's internal form. This is not useful to you: these files are in a compressed, read-only, Git-only data format. So Git expands each such file into an ordinary everyday read/write file. This ordinary read/write file goes into a folder and has an ordinary everyday file name. But this means that when Git goes to write both a/readme.txt, which requires creating a folder named a and a file named readme.txt in it, and A/README.TXT, which requires creating a folder named A and a file named README.TXT in that, you get a name collision. Only one folder, and only one file, actually get created.

索引继续保存两个文件，a/readme.txt和A/README.TXT.使用Git所谓的管道命令 之一，可以(但非常困难且烦人)更新这两个文件.请记住，虽然索引以Git冻结和压缩的格式保留文件，但您可以批量替换这些索引文件，前提是:

The index continues to hold both files, a/readme.txt and A/README.TXT. Using one of Git's so-called plumbing commands, git update-index, it's possible (but very difficult and annoying) to update both of these files. Remember that while the index holds files in Git's frozen-and-compressed format, you can replace these index files wholesale, provided that you:

1. 将数据压缩为Git的内部格式，产生Git所谓的 blob哈希ID ;
2. 提供git update-index文件名(例如a/readme.txt)和Blob哈希ID.

1. compress the data into Git's internal format, producing what Git calls a blob hash ID;
2. provide git update-index the file name, such as a/readme.txt, and the blob hash ID.

要放入内部Blob对象的数据可以来自计算机上任何位置的任何文件.它甚至不必在您的工作树中:它可以在那里或其他地方.使用git hash-object -w创建内部blob对象，并将结果哈希ID保存在变量中.然后，立即运行git update-index替换文件的索引副本.

The data to go into the internal blob object can come from any file anywhere on your computer. It need not even be in your working tree: it can be there or elsewhere. Use git hash-object -w to create the internal blob object, and save the resulting hash ID in a variable. Then, immediately run git update-index to replace the index copy of the file.

有关如何使用这两个低级管道命令中的每个命令，请参见其文档: git hash-object 和 git update-index .

For how to use each of these two low-level plumbing commands, see their documentation: git hash-object and git update-index.

请注意，这两个命令并非真正供人类使用::它们应由更面向人类的程序运行，并且只是像git add这样的命令的构建块和git rm可以使用.在此处使用git add和git rm的问题在于，这些程序希望使用计算机上找到的名称(例如A\README.TXT)而不是Git的内部文件名来处理正在工作的树文件.因此，这就是为什么您需要使用低级命令的原因，以便可以将Git内部文件的数据(a/readme.txt和A/README.TXT)存储在名称不同的文件中，然后从这些不同的文件更新Git内部文件名称.

Note that these two commands are not really meant for use by humans: they are meant to be run by programs that are more human-oriented, and are just building blocks that commands like git add and git rm can use. The problem with using git add and git rm here is that those programs want to work with your working tree files, using the names as found on your computer—such as A\README.TXT—rather than with Git's internal file names. So that's why you would need to use the low-level commands, so that you can store both of Git's internal files' data (a/readme.txt and A/README.TXT) in files with different names, and then update Git's internal files from those different names.

我忘了提到您需要读出这两个文件.有多种方法可以执行此操作，但最简单的方法可能是将git show与shell样式重定向一起使用.在sh/bash中，您将运行:

I forgot to mention that you will need to read out the two files. There are multiple ways to do this but probably the easiest is to use git show with shell-style redirection. In sh/bash, you would run:

git show HEAD:a/readme.txt > lowercase-readme
git show HEAD:A/README.TXT > uppercase-readme

可以将两个文件(具有两个不同的名称)导出到您的工作树中. Git实际上会在git checkout期间提取两个文件，但最终它们将占用一个工作树文件，其名称可能是readme.txt或README.TXT，具体取决于哪个名称"wins". Windows文件名竞赛；该文件可能出现在名为a的文件夹中，或者出现在名为A的文件夹中，具体取决于哪个 "wins"获胜者.获取Windows文件夹名称竞赛.

to get both files out, with two different names, into your working tree. Git will in fact extract both files during git checkout, but they will wind up occupying a single work-tree file, whose name might be either readme.txt or README.TXT, depending on which name "wins" the get-a-Windows-file-name competition; this file might appear in a folder named a, or one named A, depending on which of those "wins" the get-a-windows-folder-name competition.

这篇关于Git在Windows上与重复文件合并的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！